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: [RFC] canonical linespec and multiple breakpoints ...
Date: Thu, 05 May 2011 22:40:00 -0000	[thread overview]
Message-ID: <20110505224016.GB2568@adacore.com> (raw)
In-Reply-To: <m3oc3gx48l.fsf@fleche.redhat.com>

Hey Tom,

thanks for the feedback.

> I am not sure about this plan.  I think it relies on being able to
> differentiate breakpoints based on canonical linespecs, but I don't
> think it is always possible to construct these.

Indeed, I think it is true that there are going to be times when no
canonical linespec is ever going to be unique enough.  For instance,
the rather non-sensical case where two homonym routines are implemented
on the same line of code.  However:

> E.g., consider the case where a linespec resolves to two locations, one
> of which does not have debuginfo.  What is the canonical linespec for
> the debuginfo-less location?  What if there are three locations and two
> of them don't have debuginfo?  I.e., are those two consolidated into a
> single breakpoint?  What would its canonical linespec be?  Or if not
> consolidated, etc.

I think that, in a case where we have matches in code with debug
info, we shouldn't even bother looking at code without debugging
info. I think that this would be reasonable. There should be other
ways for the user to break on those instances that don't have
debug info he that's really what he meant.

> I keep coming back to the "simple" approach I sketched here:
> 
>     http://sourceware.org/ml/gdb-patches/2011-04/msg00567.html
> 
> I can try to write this up into a fuller proposal if you want.

Which part of your message would be the approach that you are
referring to?  There are two proposals that I can see:
  - the 3rd-tier breakpoint
  - one multi-location breakpoint (meaning that we break on all
    matches regardless)

The second approach is going to be really be tough to me to sell
to the Ada users. This is why I emphasized this aspect in my other
email (it was lengthy, I apologize). I have some ideas on maybe
finding a way to make it match our goals, but I'd rather make sure
I know exactly what you meant.

-- 
Joel


  reply	other threads:[~2011-05-05 22:40 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-05 16:29 Joel Brobecker
2011-05-05 20:50 ` Tom Tromey
2011-05-05 22:40   ` Joel Brobecker [this message]
2011-05-06  3:20     ` Jan Kratochvil
2011-05-06  4:42       ` Joel Brobecker
2011-05-06 18:08         ` Matt Rice
2011-05-06  7:16     ` Eli Zaretskii
2011-05-06 19:18     ` Tom Tromey
2011-05-06  7:10   ` Eli Zaretskii
2011-05-26 21:06     ` Tom Tromey
2011-05-27  7:56       ` Eli Zaretskii
2011-06-30 21:35         ` Tom Tromey
2011-07-01 18:06           ` Tom Tromey
2011-07-02  6:35             ` Eli Zaretskii
2011-07-05 19:52               ` Tom Tromey
2011-07-05 21:07                 ` Eli Zaretskii
2011-07-05 21:46                   ` Tom Tromey
2011-07-04 19:32             ` Joel Brobecker
2011-07-05  9:20               ` Jerome Guitton
2011-07-05 15:24                 ` Joel Brobecker
2011-07-05 19:53               ` Tom Tromey
2011-07-26 21:06             ` Tom Tromey
2011-07-27 15:10               ` Matt Rice
2011-07-27 16:23               ` Jan Kratochvil
2011-07-28 15:18               ` Matt Rice
2011-08-02 15:33               ` Pedro Alves
2011-08-02 17:09                 ` Tom Tromey
2011-08-02 18:00                   ` Pedro Alves
2011-11-18 19:31                     ` Tom Tromey
2012-02-16 23:31                       ` Tom Tromey
2011-07-02  6:15           ` Eli Zaretskii
2011-07-05 20:00             ` Tom Tromey
2011-05-27 10:50       ` Matt Rice
2011-05-29 13:01       ` Matt Rice
2011-07-05 20:01         ` Tom Tromey
2011-07-06  2:32           ` Matt Rice
2011-09-18 13:47 Avi Gozlan
2011-10-03 16:28 ` Tom Tromey

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=20110505224016.GB2568@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