Re: [RFAv2 3/3] Make symtab.c better styled.

["Ulrich Weigand" <uweigand@de.ibm.com>]

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