glibc and ptrace
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Richard" == Richard Hirst <[email protected]> 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
Quoted 11 lines · Jes Sorensen
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Richard" == Richard Hirst <[email protected]> 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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Richard" == Richard Hirst <[email protected]> writes:
Quoted 3 lines · Jes Sorensen
Quoted 3 lines
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
Quoted 7 lines · 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.
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