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

[David Mosberger]

>>>>> On Thu, 26 Aug 2004 08:43:01 +0100, "Thomas Hallgren" <address@hidden> 
>>>>> said:

  >> > ...  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.

  Thomas> I don't see that as a problem at all. It's the ISV's problem
  Thomas> altogether.  They, if any, should be eager to provide and
  Thomas> manage the necessary plugins.

Yeah, in theory, you're right.  In my experience, ISVs sooner or later
stop caring about release X of their software and that always creates
problems.  Not to mention that it effectively prevents
cross-debugging, for example.

  Thomas> The reason I'm pursuing this track is that we try to
  Thomas> minimize our memory consumption and this would undoubtedly
  Thomas> increase it. We don't want to create additional structures
  Thomas> for each method that we generate if it can be avoided. As I
  Thomas> said earlier, it's a *lot* of methods and we already have
  Thomas> similar structures.

Yes, I share your concern but really don't think that
libunwind-plugins are a practical solution.  I did design the dynamic
unwind-info to minimize space-consumption.  The encoding can be
particularly efficient if many procedures share the same
prolog/epilog.  Hopefully, the overhead is acceptable.

If the current encoding _really_ isn't adequate, I suppose we could
considering adding yet another layer of indirection and add support
for an interpreted byte-code which generates the dynamic unwind-info
on demand.  But this would add a fair amount of complexity and I'd
much prefer if we could avoid it.

        --david