public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "hikari at noyu dot me" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug symtab/30386] New: Thumb flag on ARMv6 Mach-O ignored, symbols assumed to not be Thumb Date: Mon, 24 Apr 2023 19:28:56 +0000 [thread overview] Message-ID: <bug-30386-4717@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2023-04-24 19:28 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-04-24 19:28 hikari at noyu dot me [this message] 2023-04-24 22:47 ` [Bug symtab/30386] " hikari at noyu dot me 2023-04-25 11:39 ` luis.machado at arm dot com 2023-04-25 11:40 ` [Bug tdep/30386] " luis.machado at arm dot com 2023-04-25 11:45 ` luis.machado at arm dot com 2023-04-25 11:51 ` luis.machado at arm dot com 2023-04-25 11:52 ` luis.machado at arm dot com 2023-04-25 14:44 ` hikari at noyu dot me 2023-04-25 15:20 ` hikari at noyu dot me 2023-04-25 15:46 ` hikari at noyu dot me 2023-04-25 16:25 ` hikari at noyu dot me 2023-04-26 5:37 ` luis.machado at arm dot com 2023-04-26 5:40 ` luis.machado at arm dot com 2023-04-26 9:27 ` hikari at noyu dot me
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-30386-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).