This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFAv2 3/3] Make symtab.c better styled.
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: palves at redhat dot com (Pedro Alves)
- Cc: philippe dot waroquiers at skynet dot be (Philippe Waroquiers), gdb-patches at sourceware dot org
- Date: Tue, 12 Feb 2019 15:04:01 +0100 (CET)
- Subject: Re: [RFAv2 3/3] Make symtab.c better styled.
Pedro Alves wrote:
> So even though function descriptors are data symbols, they're
> basically treated as text/code symbols. The msymbol_is_function
> function returns true for them, and optionally returns the resolved
> entry address (which is where we place a breakpoint).
>
> Since these function descriptor symbols represent functions, even though
> they're data symbols in the elf tables, it would seem natural to me to
> print them using the function name style.
>
> What I'm not sure is whether we'll reach print_msymbol_info with
> data descriptor symbols when we do "info functions". Seems like
> search_symbols won't consider those symbols when looking for
> functions for "info functions". So we'd find those symbols only
> with "info variables", and then we'd print them as functions?
>
> I guess it could be argued that we should fix search_symbols
> / "info functions" to consider function descriptors, and use
> msymbol_is_function in print_msymbol_info to decide whether
> to use function style. I'm not 100% sure it needs fixing, and whether
> making "info functions" find the descriptors like that is the
> desired behavior.
>
> It wouldn't be fair to impose "info functions" on PPC64 on you,
> though.
>
> So if we don't fix that (and assuming it actually needs fixing, I'm
> not sure), then I guess the question is whether we should still
> print function descriptor symbols in function style, via
> "info variable" or whatever other paths could end up calling
> print_msymbol_info in the future.
>
> I'm not 100% sure what is preferred here. Ulrich, thoughts?
In addition to the function descriptor, which is a data symbol,
we also get a function symbol for the actual code entry point,
prefixed with a dot ('.'). This is synthesized by BFD these
days.
I've just checked the current behavior on a ppc64 machine,
and we do indeed see the (synthetic) dot symbol listed under
"info functions" and the function descriptor symbol listed
under "info variables".
(gdb) info functions
[...]
Non-debugging symbols:
0x0000000010000514 .main
(gdb) info variables
[...]
Non-debugging symbols:
0x0000000010020088 main
On the other hand, "info symbol main" does dereference the
function descriptor and returns the code entry point:
(gdb) info symbol main
.main in section .text of /home/uweigand/a.out
This all is maybe not perfect, but seems reasonable enough to me.
I'm not sure it's worth spending much effort trying to "fix"
anything here.
I haven't followed the patch series in detail, do you think it
would break anything I've outlined above?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com