Re: [PATCH v2] gdbserver: linux_low: elf_64_file_p cache results

[Pedro Alves <palves at redhat dot com>]

Hi Jon,

On 08/24/2017 05:45 AM, jon@ringle.org wrote:

> The problem lied in the fact that the function elf_64_file_p() (call on
> line 7184), was returning -1 because it could not open the file (with errno
> set to EACCESS). This was because the inferior's code was dropping root
> privileges and no longer was able to read the file.

I feel like I'm missing something.  If it's the inferior that
is dropping privileges, how can that affect gdbserver?  It's gdbserver
that opens the file, not the inferior.

It'd be nice to have a testcase for this.  Would it be possible to come
up with a small reproducer?

> This patch implements a cache per file in the elf_64_file_p() function so
> that it remembers the results of a previous query for the same filename.
> 
> Since it seems that c++ is now accepted in gdb, the cache was implemented
> using std::map

Doesn't look correct, since it assumes that the 64-bit-ness
of "/proc/PID/exe" stays constant for the lifetime of gdbserver,
which is certainly false.  With "gdbserver --multi", a single gdbserver can
stay around debugging multiple processes for an undeterminate amount of time.
After the current process PID exits, nothing prevents the kernel from
reusing PID for another process.

Also, we need to clear the cache when the inferior process execs,
since a 32-bit process can well exec a 64-bit process, and vice-versa.

If caching is the right approach, then it seems to me that it'd be
much simpler/efficient to make it a new 'bool is_elf64;' field of
struct process_info_private.

Thanks,
Pedro Alves