[parisc-linux] glibc and ptrace

[parisc-linux] glibc and ptrace

[Richard Hirst]

I have a problem with ptrace.  The ptrace syscall for PTRACE_PEEK*
saves the result in *data (4th arg), whereas the man page says
it returns the result as the return value, and the 4th arg is
ignored.  userland things, like strace for example, expect the
man page behaviour.  I assumed glibc should be providing a wrapper
to translate from kernel to userland syntax, but our glibc doesn't
appear to do so.

I had a look at glibc and found the wrapper code in
sysdeps/unix/sysv/linux/ptrace.c but that isn't included in the
build.  Instead I end up with misc/ptrace.o being a raw syscall.
I then found sysdeps/unix/sysv/linux/hppa/syscalls.list and commented
out the ptrace line in there and rebuilt.  This time it looks like
misc/ptrace.o has the proper wrapper in it (although I havn't
actually tried to run it).

So, should I be fixing glibc (if removing that line is indeed a fix),
or should I be fixing our kernel source so the glibc wrapper isn't needed?
ia64, for example seems to fix it in the kernel, while sparc64 looks
like it uses the glibc wrapper.

(my strace port only works atm because it has its own wrapper, and
I'm trying to tidy that up).

Richard

Re: [parisc-linux] glibc and ptrace

[Jes Sorensen]

>>>>> "Richard" == Richard Hirst <rhirst@linuxcare.com> writes:

Richard> So, should I be fixing glibc (if removing that line is indeed
Richard> a fix), or should I be fixing our kernel source so the glibc
Richard> wrapper isn't needed?  ia64, for example seems to fix it in
Richard> the kernel, while sparc64 looks like it uses the glibc
Richard> wrapper.

I'd say fix it in the kernel if it's cheaper to do so. You can stick a
wrapper in glibc as well, but it sounds to be simpler to do in the
kernel.

Jes

Re: [parisc-linux] glibc and ptrace

[Richard Hirst]

On Tue, Dec 19, 2000 at 08:59:49PM +0100, Jes Sorensen wrote:
> >>>>> "Richard" == Richard Hirst <rhirst@linuxcare.com> writes:
> 
> Richard> So, should I be fixing glibc (if removing that line is indeed
> Richard> a fix), or should I be fixing our kernel source so the glibc
> Richard> wrapper isn't needed?  ia64, for example seems to fix it in
> Richard> the kernel, while sparc64 looks like it uses the glibc
> Richard> wrapper.
> 
> I'd say fix it in the kernel if it's cheaper to do so. You can stick a
> wrapper in glibc as well, but it sounds to be simpler to do in the
> kernel.

Kernel fix does seem more sensible, I just wonder if there is
a general move towards doing it one way rather than the other.

Richard

Re: [parisc-linux] glibc and ptrace

[Jes Sorensen]

>>>>> "Richard" == Richard Hirst <rhirst@linuxcare.com> writes:

Richard> On Tue, Dec 19, 2000 at 08:59:49PM +0100, Jes Sorensen wrote:
>>  I'd say fix it in the kernel if it's cheaper to do so. You can
>> stick a wrapper in glibc as well, but it sounds to be simpler to do
>> in the kernel.

Richard> Kernel fix does seem more sensible, I just wonder if there is
Richard> a general move towards doing it one way rather than the
Richard> other.

I don't see a trend, a kernel fix allows us to inline the syscall
which is always nice.

Jes

Re: glibc and ptrace

[Richard Hirst]

On Tue, Dec 19, 2000 at 06:22:57PM +0000, Richard Hirst wrote:
> I have a problem with ptrace.  The ptrace syscall for PTRACE_PEEK*
> saves the result in *data (4th arg), whereas the man page says
> it returns the result as the return value, and the 4th arg is
> ignored.  userland things, like strace for example, expect the
> man page behaviour.  I assumed glibc should be providing a wrapper
> to translate from kernel to userland syntax, but our glibc doesn't
> appear to do so.

Turned out I had to fix glibc to use the wrapper on parisc.  This
means our strace source will be broken for new glibc builds.  I'll
fix strace once the glibc change propagates through.  If anyone
wants to fix their own strace for testing, just remove the raw_ptrace
stuff from strace/defs.h

Richard