This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: printing pointers to global (data) variable on Windows...
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 16 Aug 2012 15:45:24 -0700
- Subject: Re: RFC: printing pointers to global (data) variable on Windows...
- References: <20120816152255.GA2836@adacore.com> <87zk5umwj3.fsf@fleche.redhat.com>
> I think the reason for this is here:
>
> http://sourceware.org/ml/gdb-patches/2012-04/msg00175.html
Thanks for the pointer!
> Joel> My second question is regarding the fact that we looking symbols for
> Joel> functions only. This probably made sense if the function was used for
> Joel> text addresses (like disass), but does it now? Or perhaps it's the
> Joel> GNU/Linux output that should be fixed, and only text symbols should
> Joel> be printed when printing addresses (somehow, I do not think that this
> Joel> would be right).
>
> IIRC the full symbol tables only record address information for text
> symbols, not for data symbols. If so, one cannot do this lookup.
I do not understand this part, though. Searches by name should return
global variables too, no?
> Ok, horrible idea. Perhaps some flag bit on the minsym instead?
> Or on the objfile?
You mean, setting a flag that allows us to know that sizes are not
available, and thus avoid the heuristics/filtering? I wish we could
have consistent behavior instead, but that might not be achievable.
I thought about setting the size to -1, but that would open its own
can of worms, I imagine, and that's not doable either, because the
symbol size is an unsigned value (as it should be, if you ask me).
Looking at the definition of struct minimal_symbol, it looks like
we'd have some room for an extra flag. But I am not sure I really
want to go that way. The filtering wouldn't be a problem if we were
searching for all global symbols, not just functions.
--
Joel