[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

0 files changed, 0 insertions, 0 deletions