/proc/${pid}/auxv

["David S. Miller" <davem@davemloft.net>]

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 :-)