This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Problem with gdb relocation of debug info
- From: Andreas Schwab <schwab at suse dot de>
- To: Mattias Bertilsson <mattias dot bertilsson at enea dot com>
- Cc: gdb at sourceware dot org, binutils at sourceware dot org
- Date: Sat, 17 Jun 2006 15:14:15 +0200
- Subject: Re: Problem with gdb relocation of debug info
- References: <4493F8EC.8040106@enea.com>
Mattias Bertilsson <mattias.bertilsson@enea.com> writes:
> It seems the reason is the relocation of the .debug_info section that is
> initiated in symfile_relocate_debug_section() in gdb/symfile.c and the
> definition of the "howto" structs in bfd/elf32-mips.c and
> bfd/elfarm-[n|o]abi.c.
>
> For powerpc, src_mask is 0, so for relocations such as R_PPC_ADDR32 the
> DOIT() macro in bfd_perform_relocation() in bfd/relocate.c will correctly
> replace what was at the patch location with the new value.
>
> For arm and mips, however, src_mask often equals dest_mask, even for
> relocations that should patch in a constant value (such as
> R_ARM_ABS32). The result for us, where the value at the patch location is
> not 0, is that we, instead of patching in a constant, end up with the sum
> of whatever was at the patch location and the new value.
For targets that use REL (intead of RELA) relocation the addend is stored
in the source field instead of the relocation entry, so ignoring the
previous section contents would be wrong. Since both ARM and MIPS use REL
relocations BFD is doing the right thing here.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."