Re: [PATCH] gdb: fix incorrect search domain in find_function_in_inferior

[Andrew Burgess <aburgess@redhat.com>]

Abhay Kandpal <abhay@linux.ibm.com> writes:

> Hi Andrew,
>
> I think this commit causes two regressions on powerpc64le-linux,
> still present on current master (e0d8f6fc386):
>
> FAIL: gdb.compile/compile.exp: expect no 5
> FAIL: gdb.compile/compile-cplus.exp: expect 5
>
> I bisected these to 32090b27e92cb8fd4998e8e8e65d43f445545bc7.  They
> reproduce on two machines here, one Fedora 43 and one Fedora 44.
>
> Both tests check that the memory used by an injected module is released
> after the compile command finishes.  After this commit it is not.
>
> Before the commit, with "set debug compile on":
>
> allocated 0x5f0 bytes at 0x7ffff7f30000 prot 5
> allocated 0x10 bytes at 0x7ffff7db0000 prot 3
> allocated 0x34 bytes at 0x7ffff7da0000 prot 1
> allocated 0x8 bytes at 0x7ffff7d90000 for registers
>
> and none of those addresses appear in "info proc mappings" once the
> command has finished.  After this commit they are still mapped,
> for example:
> (gdb) p intptr
> $1 = (int *) 0x7ffff7db0000
>
> 0x00007ffff7db0000 0x00007ffff7dc0000 0x10000  0x0  rw-p
>
> so "p *intptr" still reads 5 from the module's memory, which is what the
> tests check against.
>
> That memory is released by munmap_list::~munmap_list in
> compile/compile-object-load.c, which calls gdbarch_infcall_munmap.  On
>
> Linux that is linux_infcall_munmap (linux-tdep.c:2960), which looks up
> "munmap" with find_function_in_inferior.  The destructor discards any
> exception, so a failure there would be silent.
>
> The allocations themselves still work, and linux_infcall_mmap looks up
> "mmap64" through the same function, so whatever changed seems to affect
> the lookup of "munmap" but not "mmap64".
>
> Since GDB 18.1 is due on the 11th, I thought it was worth flagging now.

Thanks, I will investigate these, but the good news is that
32090b27e92cb8fd4998e8e8e65d43f445545bc7 is not on the gdb-18-branch.
You can confirm this with:

  $ git branch -a --contains 32090b27e92cb8fd4998e8e8e65d43f445545bc7 | grep -e "gdb-.*-branch"

which will return no hits.

But I'll still be looking into what is happening here.

Thanks,
Andrew