ARM EABI Linux, breakpoints cause SIGILL and target dies

Nicholas Sherlock
Fri Jan 20 02:45:00 GMT 2012

Hey all,

I have Ubuntu's userspace code running inside a chroot on top of
Android's Linux kernel on my phone. Using this, I've built GDB 7.3
from Ubuntu's source package. Here's the system details:

# uname -a
Linux localhost #4 PREEMPT Wed Jan 18 20:25:06 PST 2012
armv7l armv7l armv7l GNU/Linux

# cat /proc/cpuinfo
Processor       : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 163.57
Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3
CPU implementer : 0x51
CPU architecture: 7
CPU variant     : 0x1
CPU part        : 0x00f
CPU revision    : 2

Hardware        : runnymede
Revision        : 0002
EngineerID      : 0001
Serial          : 0000000000000000

Here's my source file test.c:

#include <stdio.h>

int main(void) {
  printf("Hello, world!\n");
  printf("Goodbye, world!\n");
  return 0;

I'm building it on my target with this GCC:

# gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=arm-linux-gnueabi --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/arm-linux-gnueabi
--without-included-gettext --enable-threads=posix
--libdir=/usr/lib/arm-linux-gnueabi --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold
--enable-ld=default --enable-objc-gc
--disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp
--with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror
--enable-checking=release --build=arm-linux-gnueabi
--host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)

And this command line:

gcc -g3 -static -o a.out test.c

Running a.out alone or with GDB works fine, but any operation that
causes GDB to set a breakpoint results in the target being killed by

# gdb a.out
GNU gdb (Ubuntu/Linaro 7.3.1-2011.12-0ubuntu2) 7.3-2011.12
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi".
For bug reporting instructions, please see:
Reading symbols from /root/a.out...done.
(gdb) run
Starting program: /root/a.out
Hello, world!
Goodbye, world!
[Inferior 1 (process 14296) exited normally]
(gdb) start
Temporary breakpoint 1 at 0x81f4: file test.c, line 4.
Starting program: /root/a.out

Program received signal SIGILL, Illegal instruction.
0x000081f6 in main () at test.c:4
4         printf("Hello, world!\n");
(gdb) next

Program terminated with signal SIGILL, Illegal instruction.
The program no longer exists.

I noticed that this patch was supposed to add support for SIGILL breakpoints:

And the target-specific code says that it tries to generate a SIGILL

/* However, the EABI syscall interface (new in Nov. 2005) does not look at
   the operand of the swi if old-ABI compatibility is disabled.  Therefore,
   use an undefined instruction instead.  This is supported as of kernel
   version 2.5.70 (May 2003), so should be a safe assumption for EABI
   binaries.  */

So I would expect that this would work. Another piece of the puzzle, I
have a different phone here running a different Linux kernel, but the
same Ubuntu usermode binaries, where GDB breakpoints work perfectly:

$ uname -a
Linux localhost #1 PREEMPT Wed Jul
27 21:31:24 EDT 2011 armv7l GNU/Linux

$ cat /proc/cpuinfo

Processor       : ARMv7 Processor rev 2 (v7l)
BogoMIPS: 662.40
Features: swp half thumb fastmult vfp edsp thumbee neon
CPU implementer : 0x51
CPU architecture: 7
CPU variant     : 0x0
CPU part: 0x00f
CPU revision    : 2

Hardware: mahimahi
Revision: 0081
Serial  : 0000000000000000

How do I begin to debug this problem? I have the source code available
for both kernels if there is something to investigate there.

Nicholas Sherlock

More information about the Gdb mailing list