[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).
--david