public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Tom de Vries <tdevries@suse.de>,
	gdb-patches@sourceware.org, Keith Seitz <keiths@redhat.com>
Subject: Re: [pushed] Change inline frame breakpoint skipping logic (fix gdb.gdb/selftest.exp)
Date: Thu, 28 Jun 2018 14:48:00 -0000	[thread overview]
Message-ID: <77528608-be2c-5a21-e250-36e7d56ba950@redhat.com> (raw)
In-Reply-To: <8b697d21-aa2b-15a4-e796-71c37d4c7942@redhat.com>

On 06/27/2018 05:28 PM, Pedro Alves wrote:
> Hi Joel,
> 
> On 06/26/2018 11:02 PM, Joel Brobecker wrote:
> 
>> Just a quick message that the patch makes sense to me, and that
>> I was just able to run it through AdaCore's testsuite with succes.
>> Or, I should qualify that - there is one tiny change that I haven't
>> had time to analyze, but from the surface, it is exactly what you
>> explained about why you need the second hunk.
>>
>> I haven't had a chance to run it through the official testsuite,
>> however, as I have to go ... I am so laaaaate!
>>
>> I can do that tomorrow, or if you prefer to just finish the patch
>> up and push it, it'd be perfect. I think the patch is good.
>>
>> Thanks again!
> 
> FYI, I'm starting to look at this now.

So while poking some more at this, noticed that setting a breakpoint
by address crashes in the same way, like "b *ADDRESS".  So I thought
that maybe it would be better to make stopped_by_user_bp_inline_frame
return true if the location has no symbol instead of returning
false like in the version I sent before.  That preserves the previous
behavior of showing the stop at the inline function if we miss
setting the sal's symbol somewhere.

However, playing with that made me notice something else
unrelated to my "Change inline frame breakpoint skipping"
patch:

  (gdb) b *0x40062f
  Breakpoint 2 at 0x40062f: file inline-break.c, line 32.
  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  2       breakpoint     keep y   0x000000000040062f in main at inline-break.c:32
   (gdb) r
   ....
  Breakpoint 2, func1 (x=1) at inline-break.c:32
  32        return x * 23; /* break here */

Notice that above "info break" says "in main":

   in main at inline-break.c:32
      ^^^^

Since we say "inline-break.c:32" everywhere, and present the
stop at the inline function, I think that "info break" should say instead:

   in func1 at inline-break.c:32
      ^^^^^

Fixing that ends up going back to setting the symbol in the sal
again, but I decided to do that in a separate patch, and still
make "loc->symbol == nullptr" in stopped_by_user_bp_inline_frame return
true, unlike the previous version of the patch.

I'll be sending two patches in response to this email.

Thanks,
Pedro Alves

  reply	other threads:[~2018-06-28 14:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-12 15:06 [PATCH] Ensure captured_main has unique address Tom de Vries
2018-06-12 17:38 ` Change inline frame breakpoint skipping logic (Re: [PATCH] Ensure captured_main has unique address) Pedro Alves
2018-06-14 13:22   ` Tom de Vries
2018-06-19 16:36     ` [pushed] Change inline frame breakpoint skipping logic (fix gdb.gdb/selftest.exp) Pedro Alves
2018-06-25 21:04       ` Joel Brobecker
2018-06-26 19:02         ` Pedro Alves
2018-06-26 22:02           ` Joel Brobecker
2018-06-27 16:28             ` Pedro Alves
2018-06-28 14:48               ` Pedro Alves [this message]
2018-06-28 14:50                 ` [PATCH 1/2] Fix running to breakpoint set in inline function by lineno/address Pedro Alves
2018-06-28 17:32                   ` Joel Brobecker
2018-06-28 14:50                 ` [PATCH 2/2] "break LINENO/*ADDRESS", inline functions and "info break" output Pedro Alves
2018-06-28 17:42                   ` Joel Brobecker
2018-06-29 18:43                     ` Pedro Alves

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=77528608-be2c-5a21-e250-36e7d56ba950@redhat.com \
    --to=palves@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=keiths@redhat.com \
    --cc=tdevries@suse.de \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).