Unable to stop at breakpoint in 32-bit executable
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gdb (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
I believe I'm having the problem described in #1846557 and #1848200. Those bugs were reported fixed in 8.1.1 but I'm observing them in 9.2 so I suspect a regression (in fact, if I read the notes correctly, the earlier reports were from another regression!).
I create a new EC2 server on AWS with Ubuntu Server 20.04 LTS (64-bit Arm) then perform the following installs (not sure what is needed or if something is missing):
```
sudo dpkg --add-architecture armhf
sudo apt update
sudo apt upgrade -y
sudo apt install -y build-essential vim binutils-
gdb libc6:armhf libstdc++6:armhf
```
Then I create hello.s:
```
.text
.global _start
_start:
MOV R7, #4
MOV R0, #1
LDR R1, =hello
LDR R2, =hello_size
SWI 0
MOV R7, #1
SWI 0
.data
hello: .asciz "Hello world!\n"
.equ hello_size, (.-hello)
```
Then I assemble, link, and run, all with success. Finally, I try to debug:
```
$ arm-linux-
$ arm-linux-
$ rm out.o
$ ./out
Hello world!
$ gdb out
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
...
Reading symbols from out...
(gdb) b _start
Breakpoint 1 at 0x10074: file hello.s, line 4.
(gdb) run
Starting program: /home/ubuntu/
```
At this point everything hangs until I press ^C:
```
^C
Program received signal SIGINT, Interrupt.
0x0000aaaaba072284 in ?? ()
(gdb) bt
#0 0x0000aaaaba072284 in ?? ()
#1 0x0000000000007232 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) l
1 .text
2 .global _start
3 _start:
4 MOV R7, #4
5 MOV R0, #1
6 LDR R1, =hello
7 LDR R2, =hello_size
8 SWI 0
9 MOV R7, #1
10 SWI 0
(gdb) q
A debugging session is active.
Inferior 1 [process 29234] will be killed.
Quit anyway? (y or n) y
$
```
It appears that gdb generally works and recognizes the executable, but breakpoints don't work. I'm new at Arm and don't have a lot of experience with assembly (at least not since the early 1970s), so it could easily be my problem but it seems suspiciously like an earlier problem and I think what I've done should work.
description: | updated |
This doesn't seem to be related to the previous bugs.
I tried to reproduce this on 18.04.4 (I don't have 20.04) and a fresh build of GDB master, and I couldn't.
(gdb) disass _start
Dump of assembler code for function _start:
0x00010074 <+0>: mov r7, #4
0x00010078 <+4>: mov r0, #1
0x0001007c <+8>: ldr r1, [pc, #12] ; 0x10090 <_start+28>
0x00010080 <+12>: ldr r2, [pc, #12] ; 0x10094 <_start+32>
0x00010084 <+16>: svc 0x00000000
0x00010088 <+20>: mov r7, #1
0x0001008c <+24>: svc 0x00000000
0x00010090 <+28>: muleq r2, r8, r0
0x00010094 <+32>: andeq r0, r0, lr
End of assembler dump.
(gdb) b _start
Breakpoint 1 at 0x10074: file /tmp/hello.S, line 4.
(gdb) r
Starting program: /tmp/hello
Breakpoint 1, _start () at /tmp/hello.S:4
4 MOV R7, #4
With Ubuntu 18.04.4's GDB it also works.
Can you please turn on debugging and paste the log?
Use "set debug infrun 1" before the run command.