Re: [Valgrind-users] Callgrind results on ppc

[Josef W. <Jos...@gm...>]

On Thursday 28 September 2006 21:40, Harris, Jeff wrote:
> I've made a little more progress on this issue of getting the function
> call/return tracked correctly.  I modified to toIR.c file for the
> guest-ppc in the VEX library.  For some of the PPC branch instructions,
> the code was setting the call type to either call or boring.  I tried
> modifying the code to return a type of return for the bctr instructions
> similar to the bclr instructions.  That change seemed to make the call
> trace align a lot better, especially the _dl_runtime_resolve function
> which is called a lot.

Ah, that's good to known.
I remember that I requested a similar change a long time ago...
AFAIK the only VG tool that is interpreting the kind of the jump is
Callgrind, so such a change should be easy to integrate without any
side effects.

> I still have more work, I believe, to catch some 
> other branch instructions.  I don't know how "ugly" of a fix it will be
> since my knowledge of PPC assembly and ABI is quite limited.

It really would be ugly if the jump kind depends on the context (e.g.
whether LR holds the return address or not).

> so, I found some issues in how some segments of the ELF file are
> managed.  The .plt section has some peculiar behavior on PPC.  In the
> application ELF object, the section should not be relocated, or it gets
> the wrong starting address.  In shared libraries, however, the section
> should be relocated.

So that would explain why skipping of calls into PLT sometimes is working
and sometimes not?

> I'll try and spend more time when I can getting my changes into a
> cohesive patch, once I've ironed out the bugs.

Thanks for this work,
Josef

> 
> Jeff
> 
> -----Original Message-----
> From: Julian Seward [mailto:js...@ac...] 
> Sent: Thursday, September 28, 2006 3:17 PM
> To: Josef Weidendorfer
> Cc: val...@li...; Harris, Jeff
> Subject: Re: [Valgrind-users] Callgrind results on ppc
> 
> 
> 
> > What I do know is that there is a nasty hack in m_stacktrace.c, the
> part
> > for unwinding the stack -- see VG_(get_StackTrace2) and specifically
> the
> > stuff for setting/using lr_is_first_RA.  This was from one of the IBM
> > linux guys, unfortunately moved on elsewhere now.
> 
> I later documented the trick as shown below, so at least we can see what
> 
> it is doing.
> 
> J
> 
>    /* We have to determine whether or not LR currently holds this fn
>       (call it F)'s return address.  It might not if F has previously
>       called some other function, hence overwriting LR with a pointer
>       to some part of F.  Hence if LR and IP point to the same
>       function then we conclude LR does not hold this function's
>       return address; instead the LR at entry must have been saved in
>       the stack by F's prologue and so we must get it from there
>       instead.  Note all this guff only applies to the innermost
>       frame. */
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
>