aboutsummaryrefslogtreecommitdiff
path: root/gdb/main.c
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2019-06-11 23:33:53 +0100
committerAndrew Burgess <andrew.burgess@embecosm.com>2019-07-09 10:31:21 +0100
commit5b0e2db4fa08b43e9ff78d6e9a45d496522bd241 (patch)
treea0ebcb1c70557a5a28a42339c049354f76a854af /gdb/main.c
parent0ba852ab4126a6eb4be88577d62dc25f2be7f725 (diff)
downloadgdb-5b0e2db4fa08b43e9ff78d6e9a45d496522bd241.zip
gdb-5b0e2db4fa08b43e9ff78d6e9a45d496522bd241.tar.gz
gdb-5b0e2db4fa08b43e9ff78d6e9a45d496522bd241.tar.bz2
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/main.c')
0 files changed, 0 insertions, 0 deletions