Re: [PATCH v2 1/1] gdb: Preserve IFUNC marker when finding inferior functions

[Muhammad Kamran <muhammad.kamran@arm.com>]

Hi Florian,
>> GDB calls find_function_in_inferior ("malloc") when expression
>> evaluation needs to allocate memory in the inferior, e.g. for string
>> literal arguments.
> 
> So this looks fairly nasty.  This looks fairly harmless as far as GDB
> expressions go:
> 
>> +    gdb_test "print (get_string (\"hello-ifunc\"), str_in_arena ())" \
> 
> We can actually detect the GDB call and glibc and do the right thing:
> 
>    [PATCH 0/2] Work around GDB bug overwriting __libc_malloc
>    <https://inbox.sourceware.org/libc-alpha/cover.1782766548.git.fweimer@redhat.com/>
> 
> Of course the GDB bug still needs fixing.
> 
> By the way, I don't think there is a safe way for GDB to call IFUNC
> resolvers.  IFUNC resolvers in glibc may assume the presence of extra
> data that was not there in the initial definition of the interface.
> This shouldn't matter for malloc: elf_gnu_ifunc_resolve_by_got should
> always be able obtain the pre-relocated address (except before
> relocation has happened).

Yes.  GDB should prefer the cache/GOT path and avoid resolver calls
where possible.  The patch does not make resolver calls safer or add a
new resolver-calling mechanism; it just preserves the IFUNC marker so
the existing IFUNC resolution path is used instead of calling the
resolver address as though it were malloc itself.

> 
> Does your patch change the behavior and output of this?
> 
> (gdb) print strcpy
> $1 = {<text gnu-indirect-function variable, no debug info>} 0x7ffff7e0b8f0 <strcpy_ifunc>
> 
> Currently, the workaround looks like this:
> 
> (gdb) print dlsym(0, "strcpy")
> $2 = (void *) 0x7ffff7ecb970 <__strcpy_avx2>
> 

No.  `print strcpy` uses the normal minimal-symbol evaluation path,
which already classifies GNU IFUNC symbols.  The patch only changes
find_function_in_inferior's internal fallback path.

I verified this on x86-64 with the patch applied and the output
remains unchanged.

Thanks,
Kamran

> Maybe going through dlsym would also be the right way to do the inferior
> calls involving IFUNC resolvers.  We can also provide a symbol that GDB
> can call to make the IFUNC resolver call, given its handler address.
> 
> Thanks,
> Florian
>