[Bug breakpoints/30385] New: SIGTRAP not attributed to breakpoint when its address has the Thumb bit set

["hikari at noyu dot me" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30385

            Bug ID: 30385
           Summary: SIGTRAP not attributed to breakpoint when its address
                    has the Thumb bit set
           Product: gdb
           Version: 13.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: hikari at noyu dot me
  Target Milestone: ---

On ARMv6 and some other Arm architectures, there is a convention that setting
the lowest bit of an instruction address means it's Thumb code, and if it's
unset, it's Arm code. This is something the branch instructions (BLX, BX, etc)
understand, is expected in the link register and stack frames, etc. However the
instruction address is always aligned to two bytes for Thumb code, so you must
mask off that bit to actually read the instruction etc, and consequently the PC
won't have this “Thumb bit” set.

gdb appears to understand this. In an app with no useful symbols, I may need to
tell GDB whether the function I'm setting a breakpoint in is Arm or Thumb code.
I can do this:

  (gdb) b *0x1e41
  Breakpoint 1 at 0x1e41

I can also do this:

  (gdb) set arm force-mode thumb
  (gdb) b *0x1e40
  Breakpoint 1 at 0x1e40

Both of these seem to cause a Thumb breakpoint to be set (the resulting
instruction is distinct from Arm mode). This doesn't seem to be an accident
considering the disassembly view also seems to interpret the Thumb bit
correctly.

However, it seems to cause problems for attributing the signal caused by a
software breakpoint to its breakpoint. The first example produces:

  (gdb) c
  Continuing.

  Program received signal SIGTRAP, Trace/breakpoint trap.
  0x00001e40 in test_qsort ()

Whereas the second example produces:

  (gdb) c
  Continuing.

  Breakpoint 1, 0x00001e40 in test_qsort ()

The exact same signal (SIGTRAP) and PC is reported to GDB in either case, so I
can only assume this is an issue with GDB? Presumably, the breakpoint is
considered to be at 0x1e41, but the PC is considered to be at 0x1e40, so some
simple equality check fails. It's a bit strange that this would happen though,
considering GDB seems to know 0x1e41 is actually 0x1e40 for some purposes.

----

Reproduction context:

- touchHLE (https://github.com/hikari-no-yume/touchHLE) revision
576292d56e73f4f7bad6310c75438d68e0cdac7f is the target GDB is connected to. It
emulates an ARMv6, Darwin target and implements the GDB Remote Serial Protocol.
If you want to use a build from GitHub CI on that commit, note that it also
needs the touchHLE_dylibs directory from git.
- The app running in touchHLE is "tests/TestApp.app/TestApp" from the same
revision in that repo. It is extremely small and Free Software.

Reproduction steps:

- Run touchHLE: `touchHLE tests/TestApp.app --gdb=localhost:9001`
- Run gdb: `gdb -ex 'target remote localhost:9001' tests/TestApp.app/TestApp`

If it's relevant, I am using Homebrew's build of GDB 13.1 on macOS Monterey.

----

FWIW, I might eventually try to fix this myself.

-- 
You are receiving this mail because:
You are on the CC list for the bug.