video call, week of Jan 16
Tim Newsome
YUAN SAM
Hi all,
I tried to run riscv32-unknown-elf-gdb to debug my program in my FPGA board, I found one strange behavior. Did you see the same issue in your side before? Thanks a lot for your guide.
1. target remote localhost:3333
2. info reg
It will show 64bit register information.
3. set $ra = 0x1000
when run set register command, openocd will dump error message. And it will close this target connection with gdb. According to openocd's log, it shows that gdb send a 64bit register information to openocd which is not match target.
4. load program
it also failed to load program. And openocd will close this target connection with gdb because of wrong packet size in openocd side.
5. when check riscv32-unknown-elf-gdb and it is compiled with rv32ima.
syuan@lorasrv:~/project/freedom-e-sdk/toolchain/bin$ ./riscv32-unknown-elf-gdb --version
GNU gdb (GDB) 7.12.50.20161120-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=riscv32-unknown-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Thanks again for your help.
Thanks,
Sam
Megan Wachs
--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/CY4PR18MB093651E7B921AA1F813DE1F5B3790%40CY4PR18MB0936.namprd18.prod.outlook.com.
Tim Newsome
To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/CY4PR18MB093651E7B921AA1F813DE1F5B3790%40CY4PR18MB0936.namprd18.prod.outlook.com.
YUAN SAM
Thanks a lot, Tim and Megan. It works fine in my side now.
Thanks,
Sam Yuan
发件人: Tim Newsome [mailto:t...@sifive.com]
发送时间: 2017年1月13日 2:37
收件人: Megan Wachs
抄送: YUAN SAM; RISC-V Debug Group
主题: Re: [debug] riscv32-unknown-elf-gdb issue with openocd
Tim Newsome
Tim Newsome
Megan Wachs
Timeline : This week we are taking the poll of overall approaches. Still in progress open til Friday.
Preliminary Results: 5 companies have voted, not really conclusive. “condorcet Voting” algorithm, at the moment both one-vote-per company and individual voters, the leader is “provide a choice of two interfaces”. Comments are interesting as well, take a look.
Any feedback on the poll? Nope. Tim is doing a great job.
On the list, people want to move on past the current argument. Let’s talk about the next items that will come up after the poll.
Krste: As we're standardizing an interface. We haven’t really talked about the interface to the core. If you’d like a model where there is a standard debug module with RTL that you can just re-use, we might want to talk about this. Is it worth coming up with a few standard core interfaces to enable code re-use?
Stefan would second that — not only the JTAG side, the core side should be specified beyond general interfaces.
Does it seem fair to say there should be more options here than for the SW interface?
Krste : probably for each style, there should be a suggested way to do it. But it doesn’t *have* to be exposed. It doesn’t prevent you from implementing your own interface and combining it with a core.
Stefan : Let’s say we go with both optional. For Memory Mapped, there would be an RTL interface. For instruction feeding…?
Krste : For instruction feeding you need a debug interrupt, and the CSRs, and set Debug Module on the system bus. Pretty easy to standardize
Tim : Stefan is talking about minimal gate suggested implementation… standardizing forcing instructions into the core is going to be harder to standardize. The whole point of that instruction feeding suggestion is to do things as low level as possible.
So, we agree we should standardize these interfaces, as we learn from implementing them?
Megan — I think this is more like a “recommendation of the standard” vs a requirement.
Alex — This is fundamentally less important. Useful and nice to have, but for a single implementer could be not interested at all. Expose the standard interface but internally do whatever you want.
Moving past instruction vs abstract debate (I reorganized by topic as we jumped around quite a bit) —
MIPI:
Larry -- I’ve been in contact with the Director of MIPI : Mobile Phone, automobiles, IoT, etc. Specs for cameras, displays, storage, etc. They are amenable to sharing specs if we come to some agreement. Will email Tim and Rick. They have a working group of debug and lots of spec for debug for mobile SoC.
Tim — looking at their advertising and overview, they had lots of interesting standards for debug transports that aren’t JTAG. Eg over the microSD interface. We don’t have to reinvent the wheel for the whole SoC.
Stefan — Are they closed? Is it an open spec?
Larry — This is why I’m bringing the groups together. MIPI is OK with opening their spec to RISC-V, if Rick wants to actually leverage them. They’d have to sign a letter of understanding, etc. It would be a possibility and may be free because we’re a foundation / non-profit. This is what Larry’s doing in the background with Tim’s blessing.
Tim — anything we’re going to come up with should be open and usable by anyone. Let’s see where the MIPI works leads.
Triggers:
Krste: are we talking about tracing? Or breakpoints and watchpoints?
Tim — I call them triggers because they can be used for either breakpoints or turning tracing on/off. We should re-use the trigger logic for both purposes. I have a bunch of trigger stuff in my spec which I think is reasonable. All in CSRs to avoid doing this without an actual HW debugger. Support for a lot of different options. Every chip always ends up implementing different ways of doing triggers. The spec tries to support a lot of different optional features that debugger can query to find out what's available.
In general, debuggers will probably use exact and ranges. Anything more sophisticated, the user is probably going to know this.
Richard — does GDB support triggering on a range?
Tim — I think the breakpoint can be set on address with size?
When do we trap? Before the action? or after the action? We aren’t sure the answer. Tim's current spec allows pretty much anything and the HW has to report what it does.
It’s straightforward to trap a processor on a data access. But having a trap after its completed could also be an option. But you can simulate that one by single stepping if you trap before.
But on a load, you have to get the side effect of doing the load in order to see the value. An IO register may have side effects.
Tim — I don’t have strong feelings, but certainly instructions should trap before they execute.
Are there any issues with specifying it: instruction and store before loads on return? We aren't sure, agree to continue this discussion on the mailing list.
Alex : Q about triggers — can we have more optional triggers like cross triggers? E.g. trigger A follows Trigger B then you trap?
Tim : seems like a cool feature, but I’m pretty sure I have no idea how to use that in GDB.
Alex : Most uC datasheets make a big deal about it.
Richard -- OpenRISC uses multiple cross triggers. GDB doesn’t support it, so we had to write a special debugger SW to use it. I don’t know if anyone ever used it.
Krste — is it easy to extend GDB to access these features?
Richard — GDB tells remote stub to “set a breakpoint”. It has no knowledge of linked breakpoints.
Tim — Let’s keep it in the back of our minds, but it doesn’t need to be in the first version of the spec?
Alex — a lot of things have proprietary debug tools and they use them for their proprietary hardware, and they don't care about GDB.
Krste: For us we should work on GDB to support these fancy features if we’re going to add them.
Enumeration & Heterogeneous Systems:
Richard — How many breakpoints should we spec? 3 is enough, 8 is plenty, some people say they need 128... How does Tim’s spec specify the number of triggers? It’s not limited by the size of some memory map, just the number of bits of the index.
Tim — yes, we aren’t really limiting it.
Stefan — How do we enumerate things like how many triggers, etc?
Tim — for triggers, you can only write valid values. Write the index, see if it has the value you wrote. Then it can tell if it works or not.
Krste — you want to avoid redundant ways of describing the same information. All the way through all RISC-V spec. Write-any, read legal is a standard practice in the RISC-V spec.
Tim — we do agree the debugger needs to know nothing when it’s hooked up. It should be able to figure out XLEN, how many triggers, etc.
Stefan : Enumeration and heterogenous XLEN? How do we handle that? Not a blocker, we just haven’t talked about it yet. What about extensions with registers larger than XLEN?
Do we require that any RISC-V extensions must be required to transfer any new state to a GPR?
Richard — Can GDB *request* (vs be told) the feature set of the CPU? XLEN?
Tim — I’ve been looking into this. Right now there is an issue that GDB assumes the target is 64bits. Tim is talking on GDB mailing list. They suggested there are multiple “platform types”, RV32, RV64, RV128. XLEN is a little special because it impacts a lot of low-level data structures. Another example is compressed breakpoints. You can only set that on cores that support it. When you ask GDB to set a breakpoint, it reads the MISA reg (once and caches). If compressed is supported it will use 2 byte breakpoint, else 4-byte. So GDB itself can look up things, but there isn’t a general concept of GDB’s discovery phase.
So is it generally fair to say GDB can’t currently understand different XLENs?
GDB has a concept of multiple threads but not different XLEN.
Krste — in this case, let’s work with the GDB and add support for RISC-V and all these other things. Being open and documenting and having a standard, we don’t have to do everything ourselves. Not sure who are the active GDB maintainers.
Stefan — what is the standard approach for multithread debugging on GDB? Just share the debug transport, just share different instances of GDB? Does it have to be robust against this use case? We can’t have two GDB instances interfering.
Tim — this is a use case that is going to happen. Multiple GDBs talking to multiple harts through he same Debug Transport / Debug Module. In the case of JTAG, both would connect to same HW. OpenOCD would be responsible for multiplexing.
Krste — whatever is handling DTM / DM would have to handle the multiplexing. Off the top of my head, would need to save or replay transactions. It would be better if a single GDB instance could manage the harts.
Richard — If you have two separate programs you want to debug, or maybe even two people working on SW pieces and both want to debug… they don’t really need to know what the other is doing or use the same GDB.
Stefan — so do we have to transfer the hart ID every time (do the multiplexing in HW)?
Richard — there is only (probably) one channel to the outside world. So whoever is mastering that channel can do the multiplexing. So it’s OK to set the Hart ID once and assume it doesn't change until you change it.
Krste — can we describe some sort of way we don’t have to save the state? E.g. if there are two threads you’re trying to debug are actually synchronizing on each other. Can we break it up into transactions where we don’t need to save state in the debug module? We would want it to be stateless without tying up resources, but I’m not sure you can do that in all cases.
Richard — Can see a common case where people are debugging the same HW over ethernet from their desktops
Stefan — for the moment, it’s OK to say there may be cases with heterogeneous cores, you will need two GDB instances, your transport has to handle this multiplexing, not the hardware Debug Module
Tim -- OpenOCD will do the multiplexing hard work. It already has primitives like “read register”, “read memory. Natural breakdown for operations. Doesn’t require special multiplexing stuff in debug module or JTAG.
Two separate issues : different XLEN, and different hart multiplexing. We should fix GDB to handle heterogeneous XLEN. OpenOCD is fine with it.
64-bit GDB can happily debug 32-bit RISC-V cores if told. The problem is that GDB sends 64-bit messages, and interprets OpenOCD’s as 64-bit messages, etc.
Can OpenOCD just pretend they are both 64-bit?
Maybe. It’s a good use case to keep in mind. It will expose lots of problems.
Reset:
Tim's spec tries to clarify what he means by reset. The main goal is to be able to debug a core from the first instruction it takes at reset.
Sleep/Wake
Megan - Do we need some sort of debug wakeup similar to a debug reset? The interrupt has to wake up the core.
Does GDB have concept of sleep, wakeup?
No, but maybe we could have canned commands that are platform specific.
Megan -- main goal is that we should be able to debug a core out of wakeup just as we can out of reset. Not sure how to do it or what is required, but it is a use case. May be too platform-specific for the spec.
AIs:
Sign up for next week's call
Take the poll
Discuss open questions (triggers, etc) on the mailing list
--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/CAGDihenR-aSVMsYB8Zj%2BRfNzC6zUpe0x5Q3iswWYKnBArpoDpQ%40mail.gmail.com.
Tim Newsome
To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/CAGDihenR-aSVMsYB8Zj%2BRfNzC6zUpe0x5Q3iswWYKnBArpoDpQ%40mail.gmail.com.