Re: [PATCH] Update auxv cache when inferior pid is 0 (no inferior)

[John Baldwin <jhb@FreeBSD.org>]

On 9/12/22 2:30 PM, Simon Marchi via Gdb-patches wrote:
> 
> 
> On 2022-08-05 11:46, Luis Machado via Gdb-patches wrote:
>> While adding support for MTE corefiles and running the MTE corefile tests,
>> I noticed a strange situation where loading the symbol file + core file
>> through the command line has a different behavior compared to firing up
>> GDB, loading the symbol file with the "file" command and then loading the
>> core file with the "core" command.
>>
>> I tracked this down to gdb/auxv.c:get_auxv_inferior_data returning empty
>> auxv data for pid 0, which gets cached. This is triggered by attempting to
>> read auxv data for the exec target.
>>
>> In the early stages of reading the core file, we're still using inferior pid
>> 0, so when we attempt to read auxv to determine corefile features, we get the
>> cached empty data vector again. This breaks core_gdbarch setup.
>>
>> The fix, suggested by John Baldwin, prevents caching auxv data for pid 0.
> 
> I read the thread where you discussed this with John, I'm not sure I
> completely grasp the problem yet, but this doesn't feel like the right
> fix.  It should be fine to cache the auxv data for an inferior with pid
> 0.  If the inferior's memory and the inferior's target stack don't
> change between two invocations of get_auxv_inferior_data, there's no
> reason for the auxv data to be different for both calls.  I think the
> problem is more that we don't invalidate the data at the right time.
> 
> The first call is done when only the exec target is pushed.  The second
> call is done when the core target is pushed on top of that.  It's
> expected that the returned auxv data can be different for the two calls,
> so the cache should be invalidated somewhere between them.

The problem is that the core target attaching is a multi-step process.
The auxv cache gets invalidated when the pid is changed from 0 to the
"real" value after reading the registers near the "end" of the core
target attach process.  However, in order to read the registers from the
core dump for some architectures (like Linux/AArch64), the
read_description_from_core gdbarch hook needs to be able to fetch auxv
data (specifically the AT_HWCAP bits).  This occurs while the pid is still
zero, so the old value from the exec target is still cached.

This complexity is already present in the way that we fetch an "initial"
gdbarch from the core file and then ask that gdbarch for a more detailed
target description that is used to then instantiate a second gdbarch
(the "actual" gdbarch to use for the core file).  The place to possibly
flush the auxv cache again would perhaps be just before invoking the
core read_description method.  This would need a new observer hook though
that the auxv code could hook into.

OTOH, pid 0 is rather special and short-lived, so caching auxv data for
it seems less important than caching it once a target is fully attached
to a core or running process, etc.

-- 
John Baldwin