Re: [PATCH 2/2] gdb: catch some exceptions in find_function_in_inferior

[Tom Tromey <tom@tromey.com>]

>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:

Tom> The first thing I found was that the alias system.crtl.malloc ==
Tom> malloc is present due to extra debug info in the executable.  FWIW, it
Tom> comes from ./gcc/ada/libgnat/s-crtl.ads:
Tom> ...
Tom>    function malloc (Size : size_t) return System.Address;
Tom>    pragma Import (C, malloc, "malloc");
Tom> ...

FWIW doing name lookups in Ada is weird, because Ada defaults to wild
matching.  If you want to just find the C malloc, you have to look for
"<malloc>".

So, if the code is going via any language-specific lookup route (I
didn't dig in but it probably is), then you can easily find the wrong
function.

It would be nice to fix this, but it's complicated.

Alternatively some kind of language-neutral or "force it to use C"
approach could be implemented.

Tom> In case the c function
Tom> is represented in the debug info, the alias target is found.
Tom> Otherwise, not.  This seems incorrect to me, so I filed a PR for this
Tom> ( https://sourceware.org/bugzilla/show_bug.cgi?id=34627 ).

I commented in the bug, but this is unavoidable.  The error is thrown
because gdb wants to find a function block -- but if the alias target
doesn't have debug info, no such block is available.

Tom> Looking at ada_alias_get_block_value, ISTM that using
Tom> lookup_global_symbol means that it doesn't look beyond the exec
Tom> containing the alias.  So in conclusion, I'd say the debug information
Tom> is present, but ignored.

This part seems strange in that lookup_global_symbol should search all
objfiles.  But I wonder if instead it's finding the wrong symbol due to
wild matching.  Anyway I suspect something else weird is going on.

Tom> This might be due to a gdb bug, so I filed a PR (
Tom> https://sourceware.org/bugzilla/show_bug.cgi?id=34628 ).

Tom