https://sourceware.org/bugzilla/show_bug.cgi?id=31115
--- Comment #4 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> --- Created attachment 15249 --> https://sourceware.org/bugzilla/attachment.cgi?id=15249&action=edit ELF files demonstrating the issue The testcase I'm using is GDB's pr25124.S, built with an arm-linux-gnueabihf toolchain: $ cat ~/src/binutils-gdb/gdb/testsuite/gdb.arch/pr25124.S /* Test proper disassembling of ARM thumb instructions when reloading a symbol file. Copyright 2012-2023 Free Software Foundation, Inc. This file is part of GDB. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. */ .syntax unified .thumb .text .p2align 2 .global main .thumb .thumb_func .type main, %function main: bx pc nop .code 32 mov r0, #0 bx lr .size main, .-main .section .note.GNU-stack,"",%progbits $ gcc -g -o pr25124 ~/src/binutils-gdb/gdb/testsuite/gdb.arch/pr25124.S $ gdb pr25124 Reading symbols from pr25124... (gdb) x/i main 0x103e5 <main>: bx pc (gdb) x/i main+8 0x103ed <main+7>: vrhadd.u16 d14, d14, d31 (gdb) quit Interestingly, as can be seen above "x/i main" actually works fine. it's "x/i main+8" that breaks. This is a detail that I just noticed. There's another thing I just discovered : I can reproduce GDB's bad behavior on an ELF executable (produced by GCC from the .S file), but not on a .o file produced directly by gas: $ as -g -o pr25124.o ~/src/binutils-gdb/gdb/testsuite/gdb.arch/pr25124.S $ gdb pr25124.o Reading symbols from pr25124.o... (gdb) x/i main 0x0 <main>: bx pc (gdb) x/i main+8 0x8 <main+8>: bx lr (gdb) quit Both the executable and the .o file have the LSB bit set in main's DW_AT_low_pc: Object file: <1><26>: Abbrev Number: 2 (DW_TAG_subprogram) <27> DW_AT_name : (strp) (offset: 0x97): main <2b> DW_AT_external : (flag) 1 <2c> DW_AT_low_pc : (addr) 0x1 <30> DW_AT_high_pc : (addr) 0xd Executable: <1><24>: Abbrev Number: 2 (DW_TAG_subprogram) <25> DW_AT_name : (strp) (offset: 0x97): main <29> DW_AT_external : (flag_present) 1 <29> DW_AT_type : (ref_udata) <0x2f> <2a> DW_AT_low_pc : (addr) 0x103e5 <2e> DW_AT_high_pc : (udata) 12 <1><2f>: Abbrev Number: 3 (DW_TAG_unspecified_type) <1><30>: Abbrev Number: 0 So for some reason GDB is fine with an object file containing the wrong DW_AT_low_pc in main's DIE, but not when it's with a "full blown" executable. I'm attaching the files I generated with a toolchain that uses binutils from the commit immediately before the one that introduced this behavior, and with a toolchain that uses a recent commit from trunk. Any toolchain from a distro that uses binutils >= 2.39 should be enough to demonstrate the problem. I was able to check with Ubuntu 23.04's gcc-arm-linux-gnueabihf for example, which uses binutils 2.40. -- You are receiving this mail because: You are on the CC list for the bug.
