From: Pedro Alves <palves@redhat.com>
To: Andrew Burgess <andrew.burgess@embecosm.com>,
Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb: Don't skip prologue for explicit line breakpoints in assembler
Date: Fri, 21 Jun 2019 13:43:00 -0000 [thread overview]
Message-ID: <406d910b-8b63-1e93-d340-7e9ab841ad0b@redhat.com> (raw)
In-Reply-To: <20190620232314.GJ23204@embecosm.com>
On 6/21/19 12:23 AM, Andrew Burgess wrote:
> I spent some more time trying to find a path that would call both
> 'decode_digits_list_mode' and then 'skip_prologue_sal', but I still
> can't find one.
But won't that change affect any code path that ends up in
skip_prologue_sal with explicit_line set?
E.g.:
/* Helper function for break_command_1 and disassemble_command. */
void
resolve_sal_pc (struct symtab_and_line *sal)
{
CORE_ADDR pc;
if (sal->pc == 0 && sal->symtab != NULL)
{
if (!find_line_pc (sal->symtab, sal->line, &pc))
error (_("No line %d in file \"%s\"."),
sal->line, symtab_to_filename_for_display (sal->symtab));
sal->pc = pc;
/* If this SAL corresponds to a breakpoint inserted using a line
number, then skip the function prologue if necessary. */
if (sal->explicit_line)
skip_prologue_sal (sal);
}
Is that path unreachable today?
>
> Looking back at how the explicit_line flag was originally used when
> it was added in commit ed0616c6b78a0966, things have changed quite a
> bit in the 10+ years since. There were some tests added along with
> the explicit_line flag (gdb.cp/mb-*.exp) and these all pass both in
> master and in my patched branch.
>
> My current thinking is that the explicit_line flag was no longer doing
> anything useful in master, but if someone disagrees I'd love to
> understand more about this.
I seem to recall that GDB didn't use to update a breakpoint's line
number to advance to the next line number that includes some actual
compiled code. Like if you set a breakpoint at line 10 below:
10 // just a comment
11 i++;
you end up with a breakpoint at line 11. Maybe it's old code
related to that.
Maybe I'm misremembering.
In any case, if you change this, then you also should change
the function's entry comment:
/* Adjust SAL to the first instruction past the function prologue.
If the PC was explicitly specified, the SAL is not changed.
If the line number was explicitly specified, at most the SAL's PC
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
is updated. If SAL is already past the prologue, then do nothing. */
^^^^^^^^^^
void
skip_prologue_sal (struct symtab_and_line *sal)
{
Thanks,
Pedro Alves
next prev parent reply other threads:[~2019-06-21 13:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-12 12:34 Andrew Burgess
2019-06-20 1:11 ` Kevin Buettner
2019-06-20 20:58 ` Andrew Burgess
2019-06-20 23:23 ` Andrew Burgess
2019-06-21 3:20 ` Kevin Buettner
2019-06-21 13:43 ` Pedro Alves [this message]
2019-06-22 11:06 ` Andrew Burgess
2019-06-22 11:23 ` Andrew Burgess
2019-06-24 19:16 ` Pedro Alves
2019-06-24 19:54 ` [PROTOTYPE] Make "info breakpoints" show breakpoint's specs (Re: [PATCH] gdb: Don't skip prologue for explicit line breakpoints in assembler) Pedro Alves
2019-07-03 22:37 ` Pedro Alves
2019-06-24 19:16 ` [PATCH] gdb: Don't skip prologue for explicit line breakpoints in assembler Pedro Alves
2019-07-01 17:12 ` Andrew Burgess
2019-07-01 18:03 ` [PATCHv2 0/2] Changes for explicit_line tracking, and prologue skipping Andrew Burgess
2019-07-01 18:03 ` [PATCHv2 1/2] gdb: Remove unneeded parameter from set_breakpoint_location_function Andrew Burgess
2019-07-03 22:13 ` Pedro Alves
2019-07-01 18:03 ` [PATCHv2 2/2] gdb: Don't skip prologue for explicit line breakpoints in assembler Andrew Burgess
2019-07-03 22:13 ` Pedro Alves
2019-07-01 18:21 ` [PATCH] " Pedro Alves
2019-07-02 8:28 ` Andrew Burgess
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=406d910b-8b63-1e93-d340-7e9ab841ad0b@redhat.com \
--to=palves@redhat.com \
--cc=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=kevinb@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