Why does 64-bit gdb never reach breakpoint in ARM 32 code?

2

I am running Ubuntu 20.04.1 LTS and lscpu answers the following:

Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       ARM
Model:                           0
Model name:                      Cortex-A57
Stepping:                        r1p0
BogoMIPS:                        125.00
NUMA node0 CPU(s):               0-3
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Vulnerable
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

I have created a trivial assembly language program as follows:

        .text
        .global _start
_start:
        MOV     R0, #1
        LDR     R1, =hello
        LDR     R2, =hello_size
        MOV     R7, #4
        SWI     0
        MOV     R7, #1
        SWI     0

        .data
hello:  .asciz  "Happy Friday\n"
        .equ    hello_size, (.-hello)

I compile it with the following:

arm-linux-gnueabihf-as -ggdb hello.s -o out.o
arm-linux-gnueabihf-ld out.o -o out -lc -dynamic-linker=/usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3

When I run it directly from the command line it prints the expected output ("Happy Friday\n"). I can disassemble the code as follows:

$ objdump -d out

out:     file format elf32-littlearm


Disassembly of section .text:

0001016c <_start>:
   1016c:   e3a00001    mov r0, #1
   10170:   e59f1010    ldr r1, [pc, #16]   ; 10188 <_start+0x1c>
   10174:   e59f2010    ldr r2, [pc, #16]   ; 1018c <_start+0x20>
   10178:   e3a07004    mov r7, #4
   1017c:   ef000000    svc 0x00000000
   10180:   e3a07001    mov r7, #1
   10184:   ef000000    svc 0x00000000
   10188:   0002100c    .word   0x0002100c
   1018c:   0000000e    .word   0x0000000e

I would like to run it in a debugger (as part of a class I'm teaching on ARM assembly language). Here is what I do:

$ gdb out
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
...
Reading symbols from out...
(gdb) b _start
Breakpoint 1 at 0x1016c: file hello.s, line 4.
(gdb) run
Starting program: /home/fostja/code/280/samples/out 

At this point the program hangs. Interrupting the program gives the following:


^C
Program received signal SIGINT, Interrupt.
0x0000aaaadca1a284 in ?? ()
(gdb) bt
#0  0x0000aaaadca1a284 in ?? ()
#1  0x000000000000afc7 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

I'm at a loss as to why it is hanging and never gets to the first breakpoint. At first I thought that it had something to do with Qemu emulating the instruction that should trigger the breakpoint in the debugger (I tried this first on Proxmox, so much of the discussion focuses there) but now it appears to be something to do with 32-bit and 64-bit.

A "fixed" bug in gdb seems quite similar. See this and this.

debugging
assembly
arm
gdb
asked on Stack Overflow Oct 27, 2020 by James Foster • edited Oct 29, 2020 by James Foster

1 Answer

2

This would answer it, if gdb was run outside of qemu, on host. This is not the case of this question.


You need to use gdbserver in qemu, and then connect to it.

In qemu:

(qemu) gdbserver
gdbserver
Waiting for gdb connection on device 'tcp::1234'

In gdb, you then have to connect to it (might need to adjust to be in line with output from qemu):

(gdb) target remote localhost:1234
Remote debugging using localhost:1234

Source: https://linux.postach.io/post/debugging-linux-kernel-using-virtual-machine-qemu-monitor-and-gdb (or pretty much any other website that mentions gdbserver and qemu)

answered on Stack Overflow Oct 27, 2020 by domen • edited Oct 28, 2020 by domen

User contributions licensed under CC BY-SA 3.0