Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: printing pointers to global (data) variable on Windows...
Date: Fri, 17 Aug 2012 14:23:00 -0000	[thread overview]
Message-ID: <87628hmwbr.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20120816224524.GC2798@adacore.com> (Joel Brobecker's message of	"Thu, 16 Aug 2012 15:45:24 -0700")

Tom> IIRC the full symbol tables only record address information for text
Tom> symbols, not for data symbols.  If so, one cannot do this lookup.

Joel> I do not understand this part, though. Searches by name should return
Joel> global variables too, no?

build_address_symbolic is searching for the symbol by PC:

  symbol = find_pc_sect_function (addr, section);

I think it would be reasonable, and maybe useful, if gdb could do
by-address searches for data symbols.  That was a bigger change than I
wanted to make for the "set print symbol" series though.

Tom> Ok, horrible idea.  Perhaps some flag bit on the minsym instead?
Tom> Or on the objfile?

Joel> You mean, setting a flag that allows us to know that sizes are not
Joel> available, and thus avoid the heuristics/filtering?

Yeah.

Joel> Looking at the definition of struct minimal_symbol, it looks like
Joel> we'd have some room for an extra flag.

Yes.  pahole is super for this kind of thing... it reports a pretty big
hole after target_flag_2.

Joel> But I am not sure I really
Joel> want to go that way. The filtering wouldn't be a problem if we were
Joel> searching for all global symbols, not just functions.

That would be best, but I'm out of ideas.
I think the existing check is really what we want for ELF.

Maybe for ELF we could find some way to mark symbols we don't want.
But that's just the flag idea but the sense reversed.

Tom


  reply	other threads:[~2012-08-17 14:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-16 15:23 Joel Brobecker
2012-08-16 20:07 ` Tom Tromey
2012-08-16 22:45   ` Joel Brobecker
2012-08-17 14:23     ` Tom Tromey [this message]
2012-08-17 23:16       ` Joel Brobecker
2012-08-20 15:09         ` Joel Brobecker
2012-08-20 17:50           ` Tom Tromey
2012-08-21 15:28             ` Joel Brobecker
2012-08-20 17:48         ` Tom Tromey
2012-08-21 15:36           ` Joel Brobecker
2012-09-05 14:44             ` Joel Brobecker
2012-09-06  1:28               ` asmwarrior
2012-09-06  1:44                 ` Joel Brobecker
2012-09-06  2:03                   ` asmwarrior
2012-09-10 19:08               ` Tom Tromey
2012-09-10 22:13                 ` Joel Brobecker
2012-09-11 13:49                   ` Tom Tromey
2012-09-11 21:27                     ` Joel Brobecker

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=87628hmwbr.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /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