Reported on gdb@... Confirmed on 8.3.1. --- Hi, When I was doing a regression test, I found a problem from thumb-bx-pc.exp. I load a symbol table by file command, then I use ‘disassemble main’ command and the result is correct. When I use file command again to load the same symbol table, the result of ‘disassemble main’ is wrong. Here's the log. GNU gdb (GDB) 8.2 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-elf-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) file "/home/juntao_zhao/debugger/test/8_2_repo_sdlc/run/outputs/gdb.arch/thumb-bx-pc/thumb-bx-pc" Reading symbols from /home/juntao_zhao/debugger/test/8_2_repo_sdlc/run/outputs/gdb.arch/thumb-bx-pc/thumb-bx-pc...done. (gdb) disassemble main Dump of assembler code for function main: 0x0000821c <+0>: bx pc 0x0000821e <+2>: nop 0x00008220 <+4>: mov r0, #0 0x00008224 <+8>: bx lr End of assembler dump. (gdb) file "/home/juntao_zhao/debugger/test/8_2_repo_sdlc/run/outputs/gdb.arch/thumb-bx-pc/thumb-bx-pc" Load new symbol table from "/home/juntao_zhao/debugger/test/8_2_repo_sdlc/run/outputs/gdb.arch/thumb-bx-pc/thumb-bx-pc"? (y or n) y Reading symbols from /home/juntao_zhao/debugger/test/8_2_repo_sdlc/run/outputs/gdb.arch/thumb-bx-pc/thumb-bx-pc...done. (gdb) disassemble main Dump of assembler code for function main: 0x0000821c <+0>: bx pc 0x0000821e <+2>: nop 0x00008220 <+4>: movs r0, r0 0x00008222 <+6>: b.n 0x8966 0x00008224 <+8>: vrhadd.u16 d14, d14, d31 End of assembler dump. I'm surprised and I don't know why. Could you give me some advice?
I've reproduced this with gdb master. (gdb) disass main Dump of assembler code for function main: 0x00010400 <+0>: push {r7, lr} 0x00010402 <+2>: sub sp, #8 0x00010404 <+4>: add r7, sp, #0 0x00010406 <+6>: str r0, [r7, #4] 0x00010408 <+8>: str r1, [r7, #0] 0x0001040a <+10>: ldr r3, [pc, #16] ; (0x1041c <main+28>) 0x0001040c <+12>: movs r0, r3 0x0001040e <+14>: bl 0x102dc <puts@plt> 0x00010412 <+18>: movs r3, #0 0x00010414 <+20>: movs r0, r3 0x00010416 <+22>: mov sp, r7 0x00010418 <+24>: add sp, #8 0x0001041a <+26>: pop {r7, pc} 0x0001041c <+28>: muleq r1, r0, r4 End of assembler dump. (gdb) file hello_arm Load new symbol table from "hello_arm"? (y or n) y Reading symbols from hello_arm... (gdb) disass main Dump of assembler code for function main: 0x00010400 <+0>: push {r7, lr} 0x00010402 <+2>: sub sp, #8 0x00010404 <+4>: add r7, sp, #0 0x00010406 <+6>: str r0, [r7, #4] 0x00010408 <+8>: str r1, [r7, #0] 0x0001040a <+10>: ldr r3, [pc, #16] ; (0x1041c <main+28>) 0x0001040c <+12>: movs r0, r3 0x0001040e <+14>: bl 0x102dc <puts@plt> 0x00010412 <+18>: movs r3, #0 0x00010414 <+20>: movs r0, r3 0x00010416 <+22>: mov sp, r7 0x00010418 <+24>: add sp, #8 0x0001041a <+26>: pop {r7, pc} 0x0001041c <+28>: lsls r0, r2, #18 0x0001041e <+30>: movs r1, r0 End of assembler dump.
Fix under review here: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/447
The master branch has been updated by Luis Machado <luisgpm@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bd5766ec689140aa80e5d4fd5c0bf9c990f5a38b commit bd5766ec689140aa80e5d4fd5c0bf9c990f5a38b Author: Luis Machado <luis.machado@linaro.org> Date: Fri Nov 1 10:11:17 2019 -0300 [ARM, thumb] Fix disassembling bug after reloading a symbol file The speed optimization from commit 5f6cac4085c95c5339b9549dc06d4f9184184fa6 made GDB skip reloading all symbols when the same symbol file is reloaded. As a result, ARM targets only read the mapping symbols the first time we load a symbol file. When reloaded, the speed optimization above will cause an early return and gdbarch_record_special_symbol won't be called to save mapping symbol data, which in turn affects disassembling of thumb instructions. First load and correct disassemble output: Dump of assembler code for function main: 0x0000821c <+0>: bx pc 0x0000821e <+2>: nop 0x00008220 <+4>: mov r0, #0 0x00008224 <+8>: bx lr Second load and incorrect disassemble output: Dump of assembler code for function main: 0x0000821c <+0>: bx pc 0x0000821e <+2>: nop 0x00008220 <+4>: movs r0, r0 0x00008222 <+6>: b.n 0x8966 0x00008224 <+8>: vrhadd.u16 d14, d14, d31 This happens because the mapping symbol data is stored in an objfile_key-based container, and that data isn't preserved across the two symbol loading operations. The following patch fixes this by storing the mapping symbol data in a bfd_key-based container, which doesn't change as long as the bfd is the same. I've also added a new test to verify the correct disassemble output. gdb/ChangeLog: 2019-11-01 Luis Machado <luis.machado@linaro.org> PR gdb/25124 * arm-tdep.c (arm_per_objfile): Rename to ... (arm_per_bfd): ... this. (arm_objfile_data_key): Rename to ... (arm_bfd_data_key): ... this. (arm_find_mapping_symbol): Adjust access to new bfd_key-based data. (arm_record_special_symbol): Likewise. gdb/testsuite/ChangeLog: 2019-11-01 Luis Machado <luis.machado@linaro.org> PR gdb/25124 * gdb.arch/pr25124.S: New file. * gdb.arch/pr25124.exp: New file. Change-Id: I22c3e6ebe9bfedad66d56fe9656994fa1761c485
Fixed with commit bd5766ec689140aa80e5d4fd5c0bf9c990f5a38b.