[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libunwind] gdb/idb debugger compatiblity
From: |
David Mosberger |
Subject: |
Re: [libunwind] gdb/idb debugger compatiblity |
Date: |
Thu, 25 Sep 2003 14:56:10 -0700 |
Hi Jesper,
>>>>> On Thu, 25 Sep 2003 12:59:40 +0200, "Jesper Antonsson (LM/EAB)"
>>>>> <address@hidden> said:
Jesper> We're creating a prototype JIT compiler on Itanium and would
Jesper> like idb and gdb to handle the dynamically generated code,
Jesper> i.e. generate nice backtraces and allow debugging and stack
Jesper> traversal despite dynamic code in the "middle" of the call
Jesper> stack. At first I thought libunwind could help with this,
Jesper> but now I'm unsure.
libunwind is definitely _designed_ to help with that.
Jesper> Are the debuggers currently able to interface with the
Jesper> libunwind dynamic descriptor tables somehow?
Not currently. There are folks at Red Hat working on using libunwind
for gdb/ia64. Once such as gdb is available, it will/should be able
to unwind across dynamically generated code with no problem. One open
question at the moment is whether gdb will be able to display the
procedure name of the dynamic routine (as provided by
unw_get_proc_name(3)). But I suspect that if the demand is there,
this is just a small matter of programming... ;-)
Jesper> If so, do I have to do anything in particular to make this
Jesper> work?
You'll have to register the unwind info for the dynamic code via
_U_dyn_register(), but that's the extend of it.
Jesper> I tested with test-dyn1 in the libunwind test suite, but
Jesper> even though it successfully prints its own stack trace, idb
Jesper> and gdb seem to fail.
Yes, the current gdb and idb versions do not take advantage of
libunwind.
Jesper> (I've compiled with ecc, btw, and had to modify the test
Jesper> case somewhat to make it run.
libunwind v0.92 or newer should work with ECC out-of-the-box. If it
does't, please let me know and I'll fix it.
Jesper> The procedure, "template", was larger than the size argument
Jesper> handed to memcopy.) If it isn't possible with libunwind, I
Jesper> would be very grateful for any pointers on how to otherwise
Jesper> accomplish gdb/idb dynamic code handling.
Do you have direct contacts to Red Hat? If so, you might want to ask
them for early access to a libunwind-enabled gdb. If not, let me know
and I'll see what I can do.
Unfortunately, I don't have any contacts for the idb developers.
A somewhat cheesy interim solution might be to add a libunwind-based
backtrace function to your code. With that, I think you could then do
an inferior call from within gdb to get a full backtrace. Something
along the lines of:
gdb> call libunwind_print_backtrace()
Thanks,
--david