[Bug breakpoints/18144] [aarch64] the skip prologue functionality doesn't work well for same assembly functions

["keiths at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=18144

Keith Seitz <keiths at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |keiths at redhat dot com
          Component|tdep                        |breakpoints
           Severity|normal                      |enhancement

--- Comment #1 from Keith Seitz <keiths at redhat dot com> ---
In the attachment is a reproducer:

---- from readme.txt in the attachment ----
1) The command line to compile the assembly file with debug information
aarch64-none-elf-gcc -O0 -g -nostartfiles -o main.elf main.S

2) You can see below the steps in order to reproduce the aarch64 gdb problem.
aarch64-none-elf-gdb main.elf
(gdb) b _start
Breakpoint 1 at 0x400028: file main.S, line 4.

Observed:
The breakpoint was set at the second nop instruction. 
Expected:
The breakpoint should be set at the first nop instruction.
---- end readme.txt ----

The problem here is that when you use the break command and give it a linespec
location, it *will* attempt to skip prologue instructions. Always.

However, if you give it an address location instead, gdb will *not* attempt to
skip the prologue. I guess some of us old-timers have the proper idiom hammered
into our fingers already.

Using "break *_start" should better suit your needs when debugging assembler
source files.

I am recategorizing this to "enhancement" because I think it might be desirable
to change the behavior based on the source language, e.g., if the source
language of a breakpoint location is assembler, do not do prologue-skipping. I
can see arguments both ways for this, so I will wait for maintainers to weigh
in on the issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.