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

[Petr Machata]

On Tue, 2006-08-29 at 11:14 +0530, Sharyathi Nagesh wrote:
> > My funky English doesn't do a good service here. I meant it's done on
> > top of my fedora fix, not that it's aiming to destroy the fix :)
> > 
> > > PM
> > 
> > PM
> > 
> Petr
> 	o We have observed a few of out bugs on ppc64 getting fixed
>  	because of the is_weak condition. Since as of now there is 
> 	no other way to distinguish __gmon_start__ from library calls 
> 	for the time being this patch is solving the problem. Can this
>         patch be pushed upstream soon ?

Hm, if __gmon_start__ is the only thing doing the trouble, I suppose we
could directly check for the symbol's name.  At least it won't discard
other, possibly valid weak symbols.

>   	o Please consider the patch I have submitted along with is_weak
> 	patch when pushing it upstream.

Let me look at the problem once again.  I don't even recall what was
original reason for that patch.  I'll get to that tomorrow, i.e. roughly
eight hours from now.  Would you provide me with the description of the
ppc64 problems that the patch solves?

> 	o It may be good idea to look into ptrace interface as I am 
> 	looking into a few gdb issues which on preliminary
>         analysis looks like problem with ptrace interface in ppc64.

I sent an email with explanation of what was wrong half an hour ago.
Turns out that patch passes the testsuite in redhat buildsystem on all
arches (i.e. i386, x86_64, ppc32, ppc64, ia64, s390, s390x), and the
hairs were due to hacks applied to the tree where I debugged ltrace.

Still I want to look closer if those NOPs won't magically transmute into
something useful later on, and have a talk with local gurus what the
heck is happening anyway.  This special-casing doesn't exactly make
ltrace comprehesible.

> Regards
> Sharyathi Nagesh

PM