From: Pedro Alves <palves@redhat.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: Philippe Waroquiers <philippe.waroquiers@skynet.be>,
gdb-patches@sourceware.org
Subject: Re: [RFAv2 3/3] Make symtab.c better styled.
Date: Tue, 12 Feb 2019 14:32:00 -0000 [thread overview]
Message-ID: <61a79e05-e6d7-b22b-5995-09425c370d5a@redhat.com> (raw)
In-Reply-To: <20190212140401.3F628D802C8@oc3748833570.ibm.com>
On 02/12/2019 02:04 PM, Ulrich Weigand wrote:
> 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.
>
OK.
> I haven't followed the patch series in detail, do you think it
> would break anything I've outlined above?
So the question becomes a simple cosmetic one. In this case:
> (gdb) info variables
> [...]
> Non-debugging symbols:
> 0x0000000010020088 main
Should "main" be printed with function style, or variable style.
This basically affects the color used to print the symbol.
In Philippe's patch, we'd print it in variable style. If we used
msymbol_is_function instead of his "is text symbol" check, we'd
print it in function style.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2019-02-12 14:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-12 22:28 [RFAv2 0/3] Have GDB " Philippe Waroquiers
2019-01-12 22:28 ` [RFAv2 1/3] Use function_name_style to print Ada and C function names Philippe Waroquiers
2019-01-17 22:21 ` Tom Tromey
2019-01-19 12:11 ` Philippe Waroquiers
2019-01-26 6:21 ` Joel Brobecker
2019-01-26 11:04 ` Philippe Waroquiers
2019-01-29 20:34 ` Philippe Waroquiers
2019-01-12 22:28 ` [RFAv2 2/3] Use address style to print addresses in breakpoint information Philippe Waroquiers
2019-01-12 22:28 ` [RFAv2 3/3] Make symtab.c better styled Philippe Waroquiers
2019-01-17 22:25 ` Tom Tromey
2019-02-07 18:58 ` Pedro Alves
2019-02-09 10:36 ` Philippe Waroquiers
2019-02-12 13:27 ` Pedro Alves
2019-02-12 14:04 ` Ulrich Weigand
2019-02-12 14:32 ` Pedro Alves [this message]
[not found] <20190212145443.E2799D8028D@oc3748833570.ibm.com>
2019-02-12 15:53 ` Pedro Alves
2019-02-12 18:41 ` Philippe Waroquiers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=61a79e05-e6d7-b22b-5995-09425c370d5a@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=philippe.waroquiers@skynet.be \
--cc=uweigand@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox