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

[Luis Machado <luis.machado@arm.com>]

On 9/12/22 14:53, John Baldwin wrote:
> 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.

That's what I was thinking about. If we need to invalidate it, it would be during
opening of the core file target.

> 
> 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.
> 

Also the fact that pid 0 (although a reasonable pid number) is really meant to be
"no pid", as opposed to a real pid number 0.