libunwind-devel
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]