[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [libunwind] RE: Question on libunwind-dynamic

From: David Mosberger
Subject: RE: [libunwind] RE: Question on libunwind-dynamic
Date: Wed, 15 Sep 2004 04:50:26 -0700

>>>>> On Tue, 14 Sep 2004 10:48:35 +0100, "Thomas Hallgren" <address@hidden> 
>>>>> said:

  Thomas> A half hearted attempt with a vendor specific plug-in is not
  Thomas> the right way to go.

OK, I'm happy to hear that.

Just keep in mind that I'm still open to suggestions as far as the
dynamic unwind info support is concerned.  My problem is that I don't
have a real/industrial-strength/open-source user for that stuff yet,
so if there are any design- or implementation-issues, I'm unlikely to
see them.  If you run into anything, please do let me know.

  Thomas> I have a question regarding the future of libunwind and how
  Thomas> it interacts with gdb.

  Thomas> The current gdb (6.2) make very little use of libunwind and
  Thomas> does not care about the function names that can be
  Thomas> obtained. Do you know if the gdb team has any plans to
  Thomas> change this any time soon?

I suspect libunwind currently ranks low on the GDB team's radar-screen.
I hope that as support for other platforms improves in libunwind, this
will change, but it's of course partly a chicken-and-egg problem.

I definitely would like GDB to be able to take advantage of the
procedure names for dynamically registered functions.  I'll try to
make some time for it.

  Thomas> A future gdb could do even more and use an extended
  Thomas> libunwind to obtain source file and line number. Are there
  Thomas> any plans to extend the dynamic info registered with
  Thomas> libunwind to make this possible?

"Plan" is too strong a word, but it certainly has crossed my mind.
Perhaps it would be possible to embed DWARF2 debug info in the dynamic
unwind info in some fashion.  That way, GDB might be able to take
advantage of the dynamic info without requiring a lot of new code.  It
would also mean that it would be entirely up to the program
registering the unwind info to decide how much debug info it wants to
provide (to allow making different trade-offs between efficient
dynamic code-generation and easy debugging).


reply via email to

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