[PATCH] Don't drop static function bp locations w/o debug info

[Pedro Alves]

On 9/22/20 9:20 PM, Luis Machado wrote:
> The new tests are failing for aarch64-linux-gnu on Ubuntu 18.04 (GCC 7.5.0).
> 
> The breakpoint location patterns don't seem to be matching. Here's what I see...
> 
> info breakpoint^M
> Num     Type           Disp Enb Address            What^M
> 1       breakpoint     keep y   <MULTIPLE>         ^M
> 1.1                         y   0x0000000000000794 <foo@plt+4>^M
> 1.2                         y   0x00000000000008bc <foo>^M

The test is:

	    test_info_break_2 \
		"<foo@plt.*>" \
		"<foo\\+$decimal>"

So it should be trivial to adjust with 

 -	"<foo\\+$decimal>"
 +	"<foo(\\+$decimal)?>"


However, I wonder whether we're actually seeing a bug here.
It seems like on x86, the breakpoint is set past the
prologue (thus the "+$decimal"):

 Num     Type           Disp Enb Address            What
 1       breakpoint     keep y   <MULTIPLE>         
 1.1                         y   0x0000000000001050 <foo@plt>
 1.2                         y   0x0000000000001165 <foo+8>

while it is set exactly at the function's address on Aarch64.

Why didn't GDB skip the prologue of <foo> on Aarch64?
Is there really no instruction to skip?

Here's what I see on x86-64, without debug info
 (outputs/gdb.base/msym-bp-shl/msym-bp-shl-0):

(gdb) info breakpoints 
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>         
1.1                         y   0x0000000000001050 <foo@plt>
1.2                         y   0x0000000000001165 <foo+8>

and on x86-64, with debug info
 (outputs/gdb.base/msym-bp-shl/msym-bp-shl-1):

(gdb) info breakpoints 
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>         
1.1                         y   0x0000000000001050 <foo@plt>
1.2                         y   0x0000000000001165 in foo at src/gdb/testsuite/gdb.base/msym-bp-shl-main-2.c:21

Note the location addresses are the same without vs with
debug info: 0x1050 and 0x1165.  Is that also the case on Aarch64?

Pedro Alves