[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libunwind] Api to access local variable ?
From: |
David Mosberger |
Subject: |
Re: [libunwind] Api to access local variable ? |
Date: |
Fri, 6 Jun 2003 10:23:59 -0700 |
>>>>> On Fri, 06 Jun 2003 16:40:45 +0200 (CEST), David Jobet <address@hidden>
>>>>> said:
David.Jobet> I hope I'm not out of topic. If it is, just tell me : I
David.Jobet> won't bother you anymore.
The question is perfectly on topic.
David.Jobet> I'd like to know several things : 1 - do the unwind
David.Jobet> table contains information about the local variables
David.Jobet> defined in each functions (offset / frame pointer,
David.Jobet> static type)
The unwind table(s) do _not_ contain such (debug) information.
Unwinding is quite a separate issue from debugging, though in the
past, the two were often mixed together. But with languages that
require exception handling, you need unwind info even if you don't
need debug info (hence stripping a binary will remove the debug info,
but not the unwind info).
David.Jobet> 2 - if yes, is there some functions in
David.Jobet> libunwind's api to retrieve this information or is it
David.Jobet> planned to develop these functions ? (couldn't find
David.Jobet> them)
Nope.
David.Jobet> I've read gcc uses libunwind to do exception handling.
David.Jobet> In C++, gcc have to call destructors of local variables
David.Jobet> while unwinding stack. I guessed (perhaps wrongly)
David.Jobet> that there is information in the unwind table about
David.Jobet> local variables of functions ?
No, the info about how to destroy a stack frame resides with the
compiler (and the code it generates), not the unwind library. What
the unwind library does is call a "personality" routine which takes
care of all the language-specific handling.
David.Jobet> The only information I cannot generate as static data
David.Jobet> is the address of variables in the stack frame, so I'm
David.Jobet> looking for a way to retrieve it using the unwind table
David.Jobet> (of course, provided this information does exist !)
(I see Jim just answered this portion in a separate mail, so I'll skip
this one... ;-).
--david