Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] Fix internal error on breaking at a multi-locations caller
Date: Fri, 24 Apr 2009 01:01:00 -0000	[thread overview]
Message-ID: <m3ljpqq30d.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20090309220736.GA27259@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Mon\, 9 Mar 2009 23\:07\:36 +0100")

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> patch deals with break after `up' into the caller where the caller line has
Jan> multiple locations (instances).  Discussion is contained in the code.
Jan> Original bugreport at: https://bugzilla.redhat.com/show_bug.cgi?id=488572

Thanks.

Jan> +      /* Find all the other PCs for a line of code with multiple instances
Jan> +	 (locations).  If the instruction is in the middle of an instruction
Jan> +	 block for source line GDB cannot safely find the same instruction in
Jan> +	 the other compiled instances of the same source line because the other
Jan> +	 instances may have been compiled completely differently.

[...]

Jan> +	 The current implementation will place the breakpoint at the expected
Jan> +	 returning address of the current instance of the caller.  But the
Jan> +	 other instances will get the breakpoint at the first instruction of
Jan> +	 the source line - therefore before the call would be made.  Another
Jan> +	 possibility would be to place the breakpoint in the other instances at
Jan> +	 the start of the next source line.

Based on the documentation of `break', and also my mental model of
debugging with gdb, I think that the best behavior here would be to
simply set a single breakpoint here -- the one corresponding to the
instance that is currently being executed.  Then we don't have to
worry about the other instances, and we won't set odd breakpoints
elsewhere.

What do you (or anybody) think of that?

Tom


  reply	other threads:[~2009-04-24  1:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-09 22:17 Jan Kratochvil
2009-04-24  1:01 ` Tom Tromey [this message]
2009-04-28 20:32   ` Joel Brobecker
2009-05-01  9:20     ` Jan Kratochvil
2009-05-01 15:48       ` Joel Brobecker
2009-05-01 17:32         ` Jan Kratochvil
2009-05-06 16:51           ` Joel Brobecker
2009-05-10 18:33             ` Jan Kratochvil
2009-05-11  9:11               ` Joel Brobecker
2009-05-11 15:07                 ` Jan Kratochvil

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=m3ljpqq30d.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@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