[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.

[Bug symtab/30386] 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

--- Comment #1 from hikari_no_yume <hikari at noyu dot me> ---
> - 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.

I meant to say “gdb should know the symbol *is* Thumb”, sorry.

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

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

[luis.machado at arm dot com]

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

Luis Machado <luis.machado at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luis.machado at arm dot com

--- Comment #2 from Luis Machado <luis.machado at arm dot com> ---
Could you please share the ELF file you're using?

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

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

[luis.machado at arm dot com]

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

Luis Machado <luis.machado at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|symtab                      |tdep

--- Comment #3 from Luis Machado <luis.machado at arm dot com> ---
I doubt this is a symtab issue, so I'm marking it temporarily as tdep.

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

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

[luis.machado at arm dot com]

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

--- Comment #4 from Luis Machado <luis.machado at arm dot com> ---
Eh, nevermind. I just noticed the link, sorry.

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

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

[luis.machado at arm dot com]

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

--- Comment #5 from Luis Machado <luis.machado at arm dot com> ---
Besides the fact the file isn't an ELF file, I don't see any mapping symbols in
the file either.

The thumb discovery code in gdb uses some mechanisms to figure out a particular
address/instruction is thumb. One of them is the presence of the mapping
symbols.

See here:
https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst#mapping-symbols

The other way is by looking at the address' LSB. If it is 1, then it is thumb,
otherwise it is non-thumb.

During execution, it also fetches the thumb state from the status register.

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

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

[luis.machado at arm dot com]

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

--- Comment #6 from Luis Machado <luis.machado at arm dot com> ---
I'm not sure if that helps. But if gdb doesn't know much about Mach-O for
32-bit Arm, one might need to teach it with some additional code.

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

[Bug tdep/30386] 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

--- Comment #7 from hikari_no_yume <hikari at noyu dot me> ---
Ah, sorry, I wasn't familiar with the term of art “mapping symbols”. I don't
think the Mach-O file has those, but it does have ordinary symbols for each
function, and they have a special flag that indicates they're Thumb code where
appropriate.

I'm assuming that somewhere in gdb or one of its dependencies, it either isn't
checking for that flag, or that knowledge isn't piped through to the right
place. I've managed to get gdb to build on my machine, so I'm going to see if I
can fix it.

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

[Bug tdep/30386] 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

--- Comment #8 from hikari_no_yume <hikari at noyu dot me> ---
Huh, there's already a check for the relevant flag in opcodes/arm-dis.c:

      else if (bfd_asymbol_flavour (*info->symbols)
               == bfd_target_mach_o_flavour)
        {
          bfd_mach_o_asymbol *asym = (bfd_mach_o_asymbol *)*info->symbols;

          is_thumb = (asym->n_desc & BFD_MACH_O_N_ARM_THUMB_DEF);
        }

I wonder why it doesn't work, then…

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

[Bug tdep/30386] 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

--- Comment #9 from hikari_no_yume <hikari at noyu dot me> ---
Ah, the disassembler doesn't get provided symbol info (info->symbols == NULL)
so it never gets to that branch :(

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

[Bug tdep/30386] 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

--- Comment #10 from hikari_no_yume <hikari at noyu dot me> ---
Ah, but objdump for example does provide this symbol info to the disassembler,
so objdump produces correct disassemblies in my testing with the same binary
from earlier, which has a mix of Thumb and Arm functions.

So this is specifically a gdb issue:

- it doesn't provide symbol info to the disassembler, so the disassembler can't
check for the Thumb flag
- gdb also doesn't check for the Thumb flag itself, which would be useful for
breakpoints etc

It doesn't seem like there's a simple fix for this. I tried hacking BFD to do
value |= 1 when the flag is set, and that produced really weird and broken
behaviour. A more involved fix does seem like it would be possible though.

I'm not going to actively work on this more for now, but maybe I'll come back
to it later. :)

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

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

[luis.machado at arm dot com]

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

--- Comment #11 from Luis Machado <luis.machado at arm dot com> ---
The way disassembling works for gdb is gdb passes some additional information
to the disassembler, including thumb mode. That's why binutils (objdump) and
gdb behaviors might differ in this area.

Also, if you have thumb information available for your Mach-O symbols, then it
might be just a matter of handling your OSABI better in gdb.At least for ELF we
do check the mapping symbols. Maybe  for theTraffic cones, like the ones they
used to put up in the Mach-O BFD symbols we could check the symbols themselves?

As we discussed yesterday, I don't think we have good Mach-O support for 32-bit
Arm yet. So more layers are needed by gdb to figure some of this stuff out.

Does that make sense?

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

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

[luis.machado at arm dot com]

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

--- Comment #12 from Luis Machado <luis.machado at arm dot com> ---
Heh, something weird got dumped from the clipboard. It should read...

Maybe for the Mach-O BFD symbols we could check the symbols themselves for the
thumb bits? We might need to teach gdb how to keep stripping those bits
whenever we want to use the symbols though.

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

[Bug tdep/30386] 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

--- Comment #13 from hikari_no_yume <hikari at noyu dot me> ---
I noticed that gdb seems to set up a fake symbol to mark the current PC when
disassembling, which I guess is how the disassembler knows whether the
currently executing code is Thumb or not. Is there some other mechanism to tell
the disassembler about Thumb-ness?

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