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

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

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.

Simon