Re: RFC: printing pointers to global (data) variable on Windows...

[Joel Brobecker <brobecker@adacore.com>]

> 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.

As mentioned on IRC, I just realize, now, the kind of project this is...
So, I went with the other solution, which is to mark the minimal symbols
from COFF/PE as size-less, and avoid the filtering in that case.
Attached is a patch that does that.

The patch was tested on x86-windows (using AdaCore's testsuite),
as well as on x86_64-linux.  But I am not proposing it's inclusion,
for several reasons:

  1. I strongly dislike this patch. It feels like an intrusive change
     to work around a heuristic that seems very fragile. I'd rather
     get rid of the heuristic and accept the false matches.

     I am wondering what would happen if we changed the code such that:
     If we find a function in the debugging info that matches our
     address, then use that instead of trying to see if the minimal
     symbol might be closer. When would that happen, anyway?

  2. Applying the patch fixes the problem in the sense that we now
     get the name of the symbol next to the address.  But on the
     other hand, it causes us to pick up some other (unrelated)
     symbols which were previously ignored by the heuristic. This
     is unexpected.

After working on and off on this, I do not feel very confident that
I will be able to tune the filtering to something that would satisfy
me.  So, rather than trying to do our best, I thought we might try
to do the simplest (removing the filtering of zero-sized data symbols).

Another option is for the FSF version of GDB to remain as it is,
with its bias towards GNU/Linux, while we will change AdaCore's
version to turn "set print symbol" to "off" by default...

Thoughts?
-- 
Joel