Re: [Valgrind-developers] valgrind: r10940 - in branches/ARM/coregrind: . m_debuginfo

[Julian S. <js...@ac...>]

> > * Dwarf CFI reading for ARM: it's apparently necessary to
> >    simultaneously unwind r15, r14, r13, r12 and r11.  Omitting any of
> >    those can cause the next level of the unwind to fail.  The CFI
> >    unwinder and associated data types have been changed to match this
> >    (is platform specific; need to figure out a way to merge this
> >    cleanly with the amd64 unwind stuff).
>
> I think you're supposed to unwind all the registers to be honest which
> is probably where the problem starts.

Yes, indeed.  I've been reluctant to go down that road because it
increases the costs of unwinding, which start to become significant
on memcheck in malloc/free intensive code and are very evident in
Helgrind, which unwinds very often.

It's a dog of a problem.  If you can think of a better way to be both
general and fast ...

> need all those on ARM though - well except r12 maybe (that's the static
> base pointer isn't it?).

I get the impression frame pointers on arm went the way of the dodo
around the time Thumb was introduced.  Possibly because Thumb only
allows 8 registers, so tying one up becomes a more expensive proposition.

> This is also I think the main problem that Jakub was having with PPC of
> it not unwinding enough registers and it not being easy to add extra
> registers to the set being unwound.

Uh, so we're trying to support CFI unwinding on PPC too, now?  This
seems like a good thing to me.  However, I've been scratching my head,
trying to figure out how to generalise the type DiCfSI (the unwind
summary record) and VG_(use_CF_info) (the function that uses it)
so as to be more general, yet not more expensive in time or space.
For a large program, there are zillions of DiCfSI records sloshing
around, and looking them up causes noticable L2 misses.

> Jakub's stuff that I committed also does this so there will definitely
> be some merging to do there.

Yes, I saw that too.

For some reason I didn't yet figure out, the .debug_frame reading
stuff works for .so's even though I didn't make any effort to
add text_bias values or any such onto the address range covered
by each DiCfSI.

J