From: Keith Seitz <keiths@redhat.com>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH 2/2] Report stop locations in inlined functions.
Date: Fri, 20 Oct 2017 19:02:00 -0000 [thread overview]
Message-ID: <d00a6135-6db3-7883-d02b-7b1a270fdedd@redhat.com> (raw)
In-Reply-To: <4bfba041-22f5-1650-1f83-0f8860f202fb@redhat.com>
On 07/18/2017 10:16 AM, Pedro Alves wrote:
>>
>> I don't quite like this, though. This solution involves calling
>> decode_line_full, and that is really expensive, so I would be grateful if
>> maintaienrs could offer advice on how to better tackle this.
>
> I'm still trying to grok these patches fully, but, shouldn't comparing
> the breakpoint's bp_location's addresses work the same? I.e., with this,
> gdb.opt/inline-break.exp still passes cleanly here:
I've played with your suggestion, and I *think* I am getting close. :-)
> diff --git a/gdb/inline-frame.c b/gdb/inline-frame.c
> index 006ae0d..9120554 100644
> --- a/gdb/inline-frame.c
> +++ b/gdb/inline-frame.c
> @@ -349,23 +330,19 @@ skip_inline_frames (ptid_t ptid, struct breakpoint *bpt)
> if (BLOCK_START (cur_block) == this_pc
> || block_starting_point_at (this_pc, cur_block))
> {
> - int lsal_i;
> - struct linespec_sals *lsal;
> bool skip_this_frame = true;
>
> - for (lsal_i = 0;
> - VEC_iterate (linespec_sals, canonical.sals,
> - lsal_i, lsal); lsal_i++)
> + if (bpt != NULL
> + && breakpoint_address_is_meaningful (bpt))
> {
> - struct symtabs_and_lines &sals = lsal->sals;
> -
> - for (int sals_i = 0; sals_i < sals.nelts; sals_i++)
> - {
> - struct symtab_and_line &sal = sals.sals[sals_i];
> -
> - if (sal.pc == this_pc)
> + for (bp_location *loc = bpt->loc;
> + loc != NULL;
> + loc = loc->next)
> + if (this_pc == loc->address)
> + {
> skip_this_frame = false;
> - }
> + break;
> + }
> }
>
> if (skip_this_frame)
>
The next version of this patch does this, and it works. One small addition I had to make was to /not/ skip inline frames for non-user breakpoints. step-resume breakpoints, IIRC, were otherwise broken.
Keith
next prev parent reply other threads:[~2017-10-20 19:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-11 2:36 [PATCH 1/2] Report call site for " Keith Seitz
2017-07-11 2:36 ` [PATCH 2/2] Report stop locations in " Keith Seitz
2017-07-18 17:16 ` Pedro Alves
2017-07-18 17:46 ` Pedro Alves
2017-10-20 19:21 ` Keith Seitz
2017-10-27 12:37 ` Pedro Alves
2017-10-30 21:18 ` Keith Seitz
2017-12-01 19:50 ` Pedro Alves
2017-10-20 19:02 ` Keith Seitz [this message]
2017-07-11 14:25 ` [PATCH 1/2] Report call site for " Eli Zaretskii
2017-07-17 19:23 ` Jan Kratochvil
2017-07-18 19:05 ` Pedro Alves
2017-10-20 18:46 ` Keith Seitz
2017-10-27 12:49 ` 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=d00a6135-6db3-7883-d02b-7b1a270fdedd@redhat.com \
--to=keiths@redhat.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