Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: GDB 7.4 branching status? (2011-11-23)
Date: Wed, 23 Nov 2011 23:24:00 -0000	[thread overview]
Message-ID: <20111123232406.GQ13809@adacore.com> (raw)
In-Reply-To: <m38vn6y8v6.fsf@fleche.redhat.com>

Thanks, Tom, for sending out a summary (this started out as an informal
discussion on IRC while asking Tom questions about what we were seeing
when we tried the patch out).

On second thoughts, I don't think the heuristics I proposed are
going to work. It's easy to defeat by trying to insert a breakpoint
inside a generic function (procedure Second is our Generic/Template
function here):

     7     procedure Second is
     8     begin
     9        Do_Nothing;
    10     end Second;
    11
    12     procedure Third is
    13     begin
    14        Do_Nothing;
    15     end Third;

With that, AdaCore's GDB yields:

    (gdb) b pck.adb:9
    [0] cancel
    [1] all
    [2] pck.third  <<<<----------  This one is wrong
    [3] foo.good_second

So, the idea of marking the lines below the first line of code
as suspect doesn't work. All we need is to produce the issue is
a "hole" in the linetable.

Heuristic 4 (where exact matches in a given symtab, as determine by
dirname + filename override inexact matches) isn't bad, and I think
it would prevent us from seeing the problem with generics above.
That's actually what we do today, except that we don't do the
dirname + filename check, because we're only concerned with returning
one single location.

However, I think it would miss some location as I explained using
my example with inlined functions. I think that it's a bit of
a corner case, but still legitimate.

On the other hand, the other heuristic that I like the most so far
is the simplest one, which takes the first line we find, inexact
and all. The downside is that we'll have too many matches.

> A couple of observations.
> 
> First, I think having too many locations is better than having too few.
> With too many, at least the user can disable some.  With too few,
> whoops, gdb isn't doing as asked.
> 
> Second, at least initially the heuristic only has to perform as well as
> what gdb already does.

I agree.

Right now, we're stuck between a rock and a hard place. So it's
more of a matter of deciding which approach matches our goals
the most. If we go by the principles above, the simpler heuristic
seems the way to go. It introduces an apparent regression for Ada,
but I don't see a simple way around it that does not sacrifice
a little bit of the principles above. We're just going to have
to call it a limitation.

-- 
Joel


  reply	other threads:[~2011-11-23 23:24 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-23 16:39 Joel Brobecker
2011-11-23 16:56 ` Tristan Gingold
2011-11-23 18:47 ` Tom Tromey
2011-11-23 23:24   ` Joel Brobecker [this message]
2011-11-24 10:56     ` Jerome Guitton
2011-11-24 16:33       ` Joel Brobecker
2011-11-28 16:17         ` Tom Tromey
2011-11-28 21:29         ` Tom Tromey
2011-11-29  2:28           ` Joel Brobecker
2011-11-29  2:49           ` iterate_over_symbols should be a wrapper? (was: "Re: GDB 7.4 branching status? (2011-11-23)") Joel Brobecker
2011-11-29 15:27             ` iterate_over_symbols should be a wrapper? Tom Tromey
2011-11-29  3:07           ` partial-symtab symbol sorting (was: "Re: GDB 7.4 branching status? (2011-11-23)") Joel Brobecker
2011-11-29  8:41             ` Pierre Muller
2011-11-29 14:51             ` partial-symtab symbol sorting Tom Tromey
     [not found]             ` <47228.5772244961$1322556128@news.gmane.org>
2011-11-29 14:55               ` Tom Tromey
2011-11-29  3:11           ` multiple-location breakpoint output (was: "Re: GDB 7.4 branching status? (2011-11-23)") Joel Brobecker
2011-11-29 15:06             ` multiple-location breakpoint output Tom Tromey
2011-11-29  3:14           ` decode_digits_line_mode (was: "Re: GDB 7.4 branching status? (2011-11-23)") Joel Brobecker
2011-11-29 14:56             ` decode_digits_line_mode Tom Tromey
2011-11-29  3:19           ` [RFA/commit/testcase] "info line" should not skip prologues (was: "Re: GDB 7.4 branching status? (2011-11-23)") Joel Brobecker
2011-11-29 15:03             ` [RFA/commit/testcase] "info line" should not skip prologues Tom Tromey
2011-11-29 17:00               ` Joel Brobecker
2011-11-29  3:22           ` GDB 7.4 branching status? (2011-11-23) Joel Brobecker
2011-11-29 15:38             ` Tom Tromey
2011-11-29  3:29           ` set multiple-symbol ask/cancel not working (was: "Re: GDB 7.4 branching status? (2011-11-23)") Joel Brobecker
2011-11-29 16:14             ` set multiple-symbol ask/cancel not working Tom Tromey
2011-11-29 16:57               ` Tom Tromey
2011-11-29 17:06                 ` Joel Brobecker
2011-11-30 16:41                   ` Tom Tromey
2011-11-29  3:33           ` one-too-many location in breakpoint (was: "Re: GDB 7.4 branching status? (2011-11-23)") Joel Brobecker
2011-11-29 16:15             ` one-too-many location in breakpoint Tom Tromey
2011-11-29 16:59               ` Tom Tromey
2011-11-30  5:59                 ` Joel Brobecker
2011-11-30 16:41                   ` Tom Tromey
2011-12-05 12:04                 ` Pedro Alves
2011-12-05 12:17                   ` Pedro Alves
2011-12-08 18:56                 ` Maciej W. Rozycki
2011-12-09  8:47                   ` Joel Brobecker
2011-11-24  0:58 ` GDB 7.4 branching status? (2011-11-23) Yao Qi
2011-11-24 17:17 ` Maciej W. Rozycki
2011-11-24 17:27   ` Joel Brobecker
2011-12-03  1:19     ` Maciej W. Rozycki

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=20111123232406.GQ13809@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.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