[Ltrace-devel] ltrace on ppc32 [Was: Re: ltrace is_weak patch]

[Petr Machata]

On Mon, 2006-08-28 at 23:44 +1000, Ian Wienand wrote:
> On Mon, Aug 28, 2006 at 05:43:27PM +0530, Sharyathi Nagesh wrote:
> > We had observed a few problem with current existing is_weak patch in
> > ltrace-0.5. __gmon_start__ was getting added even when is_weak
> > condition was introduced in process_breakpoint() function.
> 
> Petr Machata mentioned something very similar to me, but was unhappy
> with a similar fix IIRC.  Petr, can you comment?

The patch posted by Sharyathi Nagesh is, I believe, targeted against my
quick fedora fix.  That fedora fix is basically abusing the fact that
__gmon_start__ is weak.  I didn't post it upstream, because, um, if I
didn't write it, I'd call it a kludge.

Anyway, more ltrace bugs appeared on ppc32, that seem to be related to
the one I was targeting with my fix.  E.g., have this program:

#include <time.h>
int main (void) {
  struct timespec req = {0,0};
  nanosleep (&req, NULL);
  return 0;
}

This gives (edited to fit a call-on-a-line):

unexpected breakpoint at 0xf7fc6360
_start(1, 0xfcd4f5c4, 0xfcd4f5cc, 0xfcd4f630 <unfinished ...>
__libc_start_main(1, 0xfcd4f5c4, 0xfcd4f5cc, 0xfcd4f630 <unfinished ...>
nanosleep(1, 0xfcd4f5c4, 0xfcd4f5cc, 0xfcd4f630 <unfinished ...>
nanosleep(0xfcd4f328, 0, 0xfcd4f5cc, 0xfcd4f630) = 0
+++ exited (status 0) +++

That unexpected breakpoint on top comes from ld.so.1. Why does it
appear?  I have no idea.  If I ptrace that memory at the moment of
SIGTRAP delivery, there is simply the first instruction of ld.so.1's
_start.

_start is traced due to x_opt hack, that's ok.

The two nanosleep calls are due to the fact that link register contains
wrong address (and more mysterious breakpoints out of nowhere).  It's
nil in this example, but in other examples it can be completely wrong
address.  This way, you could end up with ltrace giving e.g. this (made
up, but have seen similar):

nanosleep(1, 0xfcd4f5c4, 0xfcd4f5cc, 0xfcd4f630 <unfinished ...>
exit(0xfcd4f328, 0, 0xfcd4f5cc, 0xfcd4f630) = 0

There is something completely foul in the way ltrace handles ppc.
Either that, or ptrace interface is broken, which I don't believe, as
other users (e.g. gdb) seem to do just fine.  Strange enough, ppc64
passes the testsuite without a scratch.

Excuse the lengthy soliloquay.

> 
> -i

PM