Messages in this thread | | | Date | Sun, 02 Apr 2006 01:14:30 -0800 (PST) | Subject | /proc/${pid}/auxv | From | "David S. Miller" <> |
| |
I think this needs to be handled by the binfmt of the current thread because the size of the auxv words themselves is binfmt dependent.
For core file output, the binfmt handler does the auxv writing and it interpretes the type of the entry words correctly.
So what happens now is that, for a 32-bit ELF binary executing on 64-bit kernel, /proc/${pid}/auxv will report an extra AT_NULL entry or garbage at the end (because it's interpreting 32-bit words as 64-bit words when trying to find the AT_NULL that ends the auxv vector). Whereas core file generation will find the end accurately and place only the exact number of AUXV entries into the core file.
There is actually a gdb testsuite case that checks that the auxv provided by /proc/${pid}/auxv matches what ends up on the core file, which is the only reason that I noticed this :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |