[libunwind] Re: Question on libunwind-dynamic

[David Mosberger]

>>>>> On Wed, 25 Aug 2004 16:30:17 +0100, "Thomas Hallgren" <address@hidden> 
>>>>> said:

  Thomas> The binary code that we are unwinding contains a lot of code
  Thomas> that is runtime generated. Reading the libunwind manual, I
  Thomas> conclude that there's two ways to deal with this.

  Thomas> 1. Register all runtime generated code using the
  Thomas> libunwind-dynamic stuff.

  Thomas> 2. Provide accessor functions that can deal with the dynamic
  Thomas> code.

As you probably know, I very much dislike the 2. approach.
It makes it impossible to backtrace through a coredump, for example.

  Thomas> Considering that we might have hundreds of thousands of
  Thomas> small functions generated, and that all information about
  Thomas> the functions can be derived from already existing
  Thomas> structures given the instruction pointer, the second
  Thomas> approach seems much more appealing.

I'd prefer to make the dynamic registration light-weight enough
that this isn't necessary.

  Thomas> It does however bring a few questions.

  Thomas> 1. It seems that the only way to use the accessors is to
  Thomas> register them with unw_init_remote. Will that incur an
  Thomas> unnecessary overhead?

Yes.  The local-only version of libunwind is quite a bit more
efficient on ia64.  Try tests/{G,L}perf-simple (depending on
libc-version, there may be an anomaly and unw_init_local() may show as
being slower in the local-only version; that's due to an inefficient
cache-coherency-check; the CVS libc should have this fixed).

  Thomas> Or is perhaps the overhead using remote in fact the use of a
  Thomas> function table?

That's mostly waht it is, but there are _lots_ of indirect calls.
Every register/memory access will go through an indirect call, whereas
in the local-only case, they result in direct memory references.

  Thomas> 2. Using the libunwind-dynamic, there is a way to register
  Thomas> things so that libunwind is globally aware of them. Would it
  Thomas> be possible to do the same thing for an accessors?

I'm not sure what you have in mind here.  The only suggestion I have
seen is to provide a dynamically-loaded extension to libunwind, but I
doubt this is a feasible solution.  I'm worried that ISVs would create
binary-only extensions to libunwind, which would make it impossible
to, e.g., unwind a particular stack from a platform which isn't
supported by the ISV.  Even when the extensions are available for the
local platform, just managing them would be a huge pain, in my
opinion.

        --david