diff options
author | Andrew Burgess <andrew.burgess@embecosm.com> | 2019-06-11 23:33:53 +0100 |
---|---|---|
committer | Andrew Burgess <andrew.burgess@embecosm.com> | 2019-07-09 10:31:21 +0100 |
commit | 5b0e2db4fa08b43e9ff78d6e9a45d496522bd241 (patch) | |
tree | a0ebcb1c70557a5a28a42339c049354f76a854af /gdb/symtab.c | |
parent | 0ba852ab4126a6eb4be88577d62dc25f2be7f725 (diff) | |
download | binutils-gdb-5b0e2db4fa08b43e9ff78d6e9a45d496522bd241.tar.gz |
gdb: Don't skip prologue for explicit line breakpoints in assembler
It was observed that in some cases, placing a breakpoint in an
assembler file using filename:line-number syntax would result in the
breakpoint being placed at a different line within the file.
For example, consider this x86-64 assembler:
test:
push %rbp /* Break here. */
mov %rsp, %rbp
nop /* Stops here. */
The user places the breakpoint using file:line notation targeting the
line marked 'Break here', GDB actually stops at the line marked 'Stops
here'.
The reason is that the label 'test' is identified as the likely start
of a function, and the call to symtab.c:skip_prologue_sal causes GDB
to skip forward over the instructions that GDB believes to be part of
the prologue.
I believe however, that when debugging assembler code, where the user
has instruction-by-instruction visibility, if they ask for a specific
line, GDB should (as far as possible) stop on that line, and not
perform any prologue skipping. I don't believe that the behaviour of
higher level languages should change, in these cases skipping the
prologue seems like the correct thing to do.
In order to implement this change I needed to extend our current
tracking of when the user has requested an explicit line number. We
already tracked this in some cases, but not in others (see the changes
in linespec.c). However, once I did this I started to see some
additional failures (in tests gdb.base/break-include.exp
gdb.base/ending-run.exp gdb.mi/mi-break.exp gdb.mi/mi-reverse.exp
gdb.mi/mi-simplerun.exp) where we currently expected a breakpoint
placed at one file and line number to be updated to reference a
different line number, this was fixed by removing some code in
symtab.c:skip_prologue_sal. My concern here is that removing this
check didn't cause anything else to fail.
I have a new test that covers my original case, this is written for
x86-64 as most folk have access to such a target, however, any
architecture that has a prologue scanner can be impacted by this
change.
gdb/ChangeLog:
* linespec.c (decode_digits_list_mode): Set explicit_line to a
bool value.
(decode_digits_ordinary): Set explicit_line field in sal.
* symtab.c (skip_prologue_sal): Don't skip prologue for a
symtab_and_line that was set on an explicit line number in
assembler code. Do always update the recorded symtab and line if
we do skip the prologue.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-break-on-asm-line.S: New file.
* gdb.arch/amd64-break-on-asm-line.exp: New file.
Diffstat (limited to 'gdb/symtab.c')
-rw-r--r-- | gdb/symtab.c | 21 |
1 files changed, 13 insertions, 8 deletions
diff --git a/gdb/symtab.c b/gdb/symtab.c index 4920d94a247..6e7e32fb4d8 100644 --- a/gdb/symtab.c +++ b/gdb/symtab.c @@ -3673,8 +3673,10 @@ skip_prologue_using_lineinfo (CORE_ADDR func_addr, struct symtab *symtab) /* 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. */ + If the line number was explicitly specified then the SAL can still be + updated, unless the language for SAL is assembler, in which case the SAL + will be left unchanged. + If SAL is already past the prologue, then do nothing. */ void skip_prologue_sal (struct symtab_and_line *sal) @@ -3693,6 +3695,15 @@ skip_prologue_sal (struct symtab_and_line *sal) if (sal->explicit_pc) return; + /* In assembly code, if the user asks for a specific line then we should + not adjust the SAL. The user already has instruction level + visibility in this case, so selecting a line other than one requested + is likely to be the wrong choice. */ + if (sal->symtab != nullptr + && sal->explicit_line + && SYMTAB_LANGUAGE (sal->symtab) == language_asm) + return; + scoped_restore_current_pspace_and_thread restore_pspace_thread; switch_to_program_space_and_thread (sal->pspace); @@ -3812,12 +3823,6 @@ skip_prologue_sal (struct symtab_and_line *sal) sal->pc = pc; sal->section = section; - - /* Unless the explicit_line flag was set, update the SAL line - and symtab to correspond to the modified PC location. */ - if (sal->explicit_line) - return; - sal->symtab = start_sal.symtab; sal->line = start_sal.line; sal->end = start_sal.end; |