libunwind-devel
[Top][All Lists]
Advanced

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

Re: [libunwind] remote unwinding and dynamically-generated code


From: David Mosberger
Subject: Re: [libunwind] remote unwinding and dynamically-generated code
Date: Wed, 15 Dec 2004 09:57:55 -0800

>>>>> On Tue, 14 Dec 2004 17:23:34 -0600 (CST), Todd L Miller <address@hidden> 
>>>>> said:

  Todd>         Two questions.  The first is most likely wishful
  Todd> thinking: will _U_dyn_register() affect the results of a
  Todd> remote unwinding?

Yes, it does.  For example, with the gdb v6.3, you can backtrace over
dynamically generated code assuming you have libunwind installed and
the code-generator uses _U_dyn_register().

  Todd>         The second question is related: does the documentation
  Todd> specify anything about how dynamic unwind information for a
  Todd> remote process is supposed to be registered, and if not, could
  Todd> it?

It could and it probably should.  It would be good to have an abstract
interface to support registration simply because doing this in a
race-free manner is fairly tricky and may involve
architecture-specific solutions to implement lock-free, yet atomic
registration.  In other words, nastiness that's best hiddien in a
library so apps don't have to reinvent the wheel.

  Todd>         I believe I've discussed adding an explicit interface
  Todd> for remote registration with DMT before, and came to the
  Todd> conclusion that it would be more trouble than it would be
  Todd> worth to do it Right.  The concern prompting the question
  Todd> above stems from the fact that my tool now works with an
  Todd> unmodified (0.98.2 or 0.98.3) libunwind, and I can say "or
  Todd> higher" with a reasonable amount of confidence, given those
  Todd> discussions.  My boss, however, would like to see something in
  Todd> the docs or API about this symbol, mostly as a concrete sign
  Todd> that it's not intended to change (despite, for the most part,
  Todd> being an internal implementation detail).

I wouldn't go as far as saying "more trouble than it would be worth".
It is something that would require some thought and perhaps 2 or 3
iterations to get right.

        --david

reply via email to

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