Unable to stop at breakpoint in 32-bit executable

Bug #1901966 reported by James Foster
10
This bug affects 2 people
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-arm-linux-gnueabi \
  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-gnueabi-as -ggdb -mcpu=cortex-a57 -o out.o hello.s
$ arm-linux-gnueabi-ld out.o -dynamic-linker=/usr/lib/ld-linux-armhf.so.3 -o out
$ 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/280/out
```

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
Revision history for this message
Luis (freezehawk) wrote :

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.

Revision history for this message
James Foster (ubuntu-a6a) wrote :

I've been able to reproduce the problem on 32-bit Ubuntu 20.04 for RPi4. The problem reproduces when the following is linked:

ld-linux-armhf.so.3 -> ld-2.31.so*

fostja@cptr280-arm:~/code/asm$ gdb -q hello
GEF for linux ready, type `gef' to start, `gef config' to configure
75 commands loaded for GDB 9.2 using Python engine 3.8
[*] 5 commands could not be loaded, run `gef missing` to know why.
Reading symbols from hello...
gef➤ set debug infrun 1
gef➤ b _start
Breakpoint 1 at 0x1016c: file hello.s, line 5.
gef➤ start
infrun: infrun_async(1)
infrun: proceed (addr=0xb6fd5a80, signal=GDB_SIGNAL_0)
infrun: proceed: resuming process 10100
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10100] at 0xb6fd5a80
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = ignore
infrun: handle_inferior_event status->kind = ignore
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = ignore
infrun: handle_inferior_event status->kind = ignore
infrun: prepare_to_wait

When I revert to the following then things work properly:

ld-linux-armhf.so.3 -> ld-2.28.so*

So I have a work-around. It appears that the problem was introduced between 2.28 and 2.31.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gdb (Ubuntu):
status: New → Confirmed
Revision history for this message
Hyun (hyunwoo-park) wrote :
Download full text (4.5 KiB)

I have same issue as James described. A static link of execution file, "-static" option in gcc, works in gdb while shared is not.
Any updates on this issue?

bulssi@bulssi:~/work$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04 LTS"
bulssi@bulssi:~/work$ lscpu
Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0,1
Off-line CPU(s) list: 2,3
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
Vendor ID: ARM
Model: 0
Model name: Cortex-A55
Stepping: r2p0
BogoMIPS: 100.00
L2 cache: 256 KiB
L3 cache: 512 KiB
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
bulssi@bulssi:~/work$ uname -a
Linux bulssi 5.4.96+ #4 SMP PREEMPT Tue Sep 28 02:25:02 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
bulssi@bulssi:~/work$ cat test.c

#include <stdio.h>

int main (int argc, char **argv)
{
        printf ("hello\n");
        return 0;
}
bulssi@bulssi:~/work$ arm-linux-gnueabihf-gcc -o a32.out test.c
bulssi@bulssi:~/work$ ./a32.out
hello
bulssi@bulssi:~/work$ gdb ./a32.out
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.

...

Reading symbols from ./a32.out...
(No debugging symbols found in ./a32.out)
(gdb) set architecture arm
The target architecture is assumed to be arm
(gdb) r
Starting program: /home/bulssi/work/a32.out
^C
Program received signal SIGINT, Interrupt.
0xf7fd12c4 in ?? () from /lib/ld-linux-armhf.so.3
(gdb) bt
#0 0xf7fd12c4 in ?? () from /lib/ld-linux-armhf.so.3
#1 0xf7fc81e4 in ?? () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
(gdb) set debug infrun 1
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/bulssi/work/a32.out
infrun: infrun_async(1)
infrun: proceed (addr=0xf7fc5a80, signal=GDB_SIGNAL_0)
infrun: proceed: resuming process 19335
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 19335] at 0xf7fc5a80
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = ignore
infrun: handle_inferior_event status->kind = ignore
infrun: prepare_to_wait

^Cinfrun: target_wait (-1.0.0, status) =
infrun: 19335.19335.0 [process 193...

Read more...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.