[Bug symtab/30386] New: Thumb flag on ARMv6 Mach-O ignored, symbols assumed to not be Thumb

[Bug symtab/30386] New: Thumb flag on ARMv6 Mach-O ignored, symbols assumed to not be Thumb

[hikari at noyu dot me]

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

            Bug ID: 30386
           Summary: Thumb flag on ARMv6 Mach-O ignored, symbols assumed to
                    not be Thumb
           Product: gdb
           Version: 13.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: hikari at noyu dot me
  Target Milestone: ---

https://github.com/hikari-no-yume/touchHLE/blob/576292d56e73f4f7bad6310c75438d68e0cdac7f/tests/TestApp.app/TestApp
is an ARMv6 Mach-O binary (for iPhone OS 2.0) with both Thumb and Arm functions
in it.

If I ask gdb to disassemble the “test_qsort” function, it assumes it's Arm
code:

  (gdb) disass test_qsort
  Dump of assembler code for function test_qsort:
     0x00001e40 <+0>:   svcge   0x0003b5f0
     0x00001e44 <+4>:   stcmi   0, cr11, [r9], #-592    @ 0xfffffdb0

This is a nonsensical disassembly, it's actually a Thumb function. Doing `set
arm fallback-mode thumb` does not change the result, which suggests gdb thinks
this is definitely not Thumb code, rather than not being sure. Using force-mode
to override this this works though:

  (gdb) set arm force-mode thumb
  (gdb) disass test_qsort
  Dump of assembler code for function test_qsort:
     0x00001e40 <+0>:   push    {r4, r5, r6, r7, lr}
     0x00001e42 <+2>:   add     r7, sp, #12
     0x00001e44 <+4>:   sub     sp, #80 @ 0x50
     0x00001e46 <+6>:   ldr     r4, [pc, #164]  @ (0x1eec <test_qsort+172>)

Anyway, when force-mode *isn't* used as a workaround, things get particularly
weird if you set a breakpoint at that function (see
https://sourceware.org/bugzilla/show_bug.cgi?id=30385 for how to test that).
When execution stops at that breakpoint, the CPU is of course in Thumb mode
(note the CPSR value):

  (gdb) c
  Continuing.

  Breakpoint 1, 0x00001e40 in test_qsort ()
  (gdb) info reg
  […]
  pc             0x1e40              0x1e40 <test_qsort>
  cpsr           0x60000030          1610612784

Despite that, opening the TUI disassembly view with `layout asm` produces the
incorrect (Arm) disassembly for the current function. This only happens when
there's symbols: if there's no symbols loaded, gdb looks at the CPSR and
correctly determines it should disassemble in Thumb mode. This is another thing
that makes me think gdb is interpreting the symbols wrong. 

I think this behaviour is a bug in gdb, because:

- The Mach-O binary (TestApp) has set the N_ARM_THUMB_DEF flag in the n_desc
field for the relevant symbol (_test_qsort), so gdb should know the symbol
isn't Thumb.
- If gdb simply isn't sure if the symbol is Thumb or not, it should be
respecting the fallback-mode.
- Thumb support is a part of ARMv6, so gdb shouldn't assume functions aren't
Thumb except when in fallback-mode.

FWIW, I might eventually try to fix this myself.

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