GDB BoF at the 2009 GCC Summit - Tuesday June 9th, 2009
Joel Brobecker, Stan Shebs, Michael Snyder and Ulrich Weigand hosted a Q&A BoF. Here is a summary of the various items that were discussed during that session.
Are we going to rewrite GDB in C++? |
- Need good C++ debugger as a pre-requisite (project Archer)
- Looking at what happens with GCC
Same issues as discussed this morning during the GCC Q&A with members of the GCC SC.
(Note from the author: There was a poll during the GCC Q&A session asking who was in favor of moving the compiler to C++, and the resuls were slightly less than 50% in favor, a few against, and the rest were undecided)
Process record for reverse debugging in GDB parses the side-effects of every instruction that gets executed. Other projects also implement knowledge of what the instructions do: the GCC machine description; qemu, which actually even emulates these instructions. Are there plans to share code? |
- We suppose we could try, if there was interest in that
How about debugging optimized code? |
- This is mostly an issue with the debugging information generated by GCC. There is an on-going project to always generate correct debugging info (and as complete as possible, or rather as complete as reasonable).
Remark: Debug info breakage between GCC releases... |
- The GCC testsuite has very few testcases that verify debugging info...
What's the status of the "inline" patch? |
- Still stuck in discussion.
IWBN: If inferior goes into endless loop that causes a stack overflow, user would like to make inferior function call as part of his analysis of the problem. But since there is no longer any stack space available, he'd like to be able to find some stack space that could be used to make the call: drop a few of the frames, or use an alternate stack to make the call. |
- Solution offered: Use "return" a few times, enough to make the function call.
IWBN: Would like to do "stuff" when the program goes through a specific location in the code. For instance, print a trace every time some code is executed. Cannot use breakpoint and an associated command list because there is no way to resume the execution as if the breakpoint was never hit. for instance, one cannot use "continue" in the commands list, because the breakpoint might have been hit while doing a "next". |
- One of the solution discussed would be to have a new possible command that would resume the previous operation, whatever it was. For instance, if the previous operation was a "next", then resume the same "next" operation. Then a user could use a breakpoint commands list and end it with that new command. No discussion on how actually feasible that is.
"set $sp = ..." does not work on x86-linux. Errors out with "sp is not an lval". |
- Solution: Use "set $esp = ..." ("sp" is only an alias for esp allowing reading of esp, but not writing). Surprisingly for the user, "set $pc = ..." DOES work! Can we make it work for $sp???
Remark: Reverse debugging seems to be working with gdbserver. |
- MichaelS and Hui did notice that, and are almost ready to claim support.
"set confirm off; return" does NOT return??? |
- Sounds like a bug.
IWBN: To have a way to change the default answer for a specific query. |
- Background: In eclipse, user does a memory write using an MI command while in the middle of a precord session. This causes precord to delete all history past this point, and so GDB asks user to confirm first. As Eclipse does not run GDB in terminal, the query is auto-answered, and the memory write gets canceled.
- As this is using an MI command, in a way, the confirmation should not be requested. The GUI should have made the request on its own before sending the MI command, and then GDB should not do a query on the console.
- A way of changing the default for a specific query might still be interesting in other situations.
IWBN: Ignore count for breakpoints: Allow an ignore count that's actually a range |
- The range is useful in non-stop mode, where you want to ignore the first N hits for a breakpoints, then leave the breakpoint active for the next M hits while the other threads are running, and finally make it inactive once these M hits have happened.
- Note: A range of N to N+1 can be achieved by using ignore-count = N and the command "enable breakpoint once".