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: Mon, 20 Aug 2012 17:48:00 -0000	[thread overview]
Message-ID: <87r4r1h2u4.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20120817231554.GF2798@adacore.com> (Joel Brobecker's message of	"Fri, 17 Aug 2012 16:15:54 -0700")

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

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

I accept that, but there's another way of looking at it.

It is just a fact that some minimal symbol readers can supply size
information, while others cannot.  Right now, this difference is
obscured in the gdb internals -- if you have a minimal symbol you can't
determine whether the size is "zero but valid" or "invalid".

So, supplying the flag makes gdb better model reality.  In this sense it
is an improvement.  Now, whether it is a *useful* improvement... :)

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

Yeah, I don't know.

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

It seems to me that the filter is correct: if you are on a platform
where minimal symbol sizes are valid, and you see a symbol of size zero,
it does not make sense to print such a symbol.  It is, I think, a symbol
that doesn't name a whole object, but rather just some marker in the
assembly.

The code for the filter is actually somewhat goofier, allowing text
symbols through.  That just corresponds to gdb's historical behavior; I
am not sure whether or not it is reasonable behavior, but it didn't make
sense to change it in the context of that patch.  At least, the intent
is to have it provide the historical behavior; in the past I think
build_address_symbolic was only called for functions.

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

If you disable "set print symbol", how would that differ from leaving
the filter in place?

Tom


  parent reply	other threads:[~2012-08-20 17:48 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
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 [this message]
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=87r4r1h2u4.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