In article <20170329195230.d895af...@cvs.netbsd.org>,
Kamil Rytarowski <source-changes-d@NetBSD.org> wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Wed Mar 29 19:52:30 UTC 2017
>
>Modified Files:
> src/sys/kern: core_elf32.c sys_ptrace_common.c
>
>Log Message:
>Generate ELF AUXV for core(5) and ptrace(2) limited to the vector TYPE x V
>
>Previously PT_DUMPCORE and PIOD_READ_AUXV and regular core dumping retrieved
>the vector of AuxInfo {a_type, a_v} + MAXPATHLEN + ALIGN(1).
>
>The extra data is not actually needed in the returned chunk. It can be
>retrieved with PT_READ_I operations and it's the preferred way to access
>them as the AuxInfo fields contain pointers (void* format) to them.
>
>This changes the behavior of the kernel, no stable releases are affected
>with this move. Current software is not affected as other systems already
>stop generating data on AT_NULL. This streamlines the NetBSD behavior with
>other ELF format OSes. This move also simplifies determination if we got
>all the needed data inside the debugger and we no longer need to eliminate
>the unneeded chunk at the end.
This is both incomplete and broken:
1. The size needed is not just the maximum number of entries * the size of
an entry. You have to account for the string entry storage that
AT_SUN_EXECNAME needs (and alignment).
2. There are other places where es_arglen is used, and needs to be cleaned
up not to mention all the size info defines in the emulations
(svr4/osf1/linux).
3. You can't assume that ELF_AUX_ENTRIES is the max number of entries needed
since emulations might need more (they currently don't) and some need
less.
In other words, you strictly made the situation worse and you possibly broke
coredumps. Fortunately you did not break exec code :-)
christos
