Problem with gdb relocation of debug info

Problem with gdb relocation of debug info

[Mattias Bertilsson]

Hello,

We're working on a gdb port for the OSE rtos. We have run into a problem 
with how gdb/bfd handles relocation information for the debug info and 
would much appreciate ideas on how to fix it.

OSE relocatable executable elf files are linked to an absolute address, 
but still have relocation information (so that the runtime loader can 
move .text .bss, etc and patch as appropriate). To be specific we do:

ld -o [intermediate] -r [objs] --start-group [libs] --end-group  --cref 
--discard-none -M
ld -o [exe] [intermediate] -T [lcf] -n --emit-relocs -e [crt0] --cref 
--discard-none -M

Now, in our gdb backend we fetch the real section addresses at runtime, 
when we supply the symbol file to the rest of gdb. This works well for 
powerpc, but fails for arm and mips, where gdb will get the address 
wrong for all symbols that have debug info.

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.

What is the best solution to this? Change src_mask to 0 for all 
relocations that should patch in constant values (which ones)? Or would 
that just break something else?

We have been working with gdb 6.3 and binutils 2.15, but I believe this 
issue is the same with newer versions.


/Mattias Bertilsson

Re: Problem with gdb relocation of debug info

[Andreas Schwab]

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."

Re: Problem with gdb relocation of debug info

[Andreas Schwab]

Mattias Bertilsson <mattias.bertilsson@enea.com> writes:

> Do you have any thoughts on the chances that we might get away with the
> quick and dirty fix of treating simple relocations such as R_ARM_ABS32 REL
> as RELA in our gdb port?

You might want to grep for partial_inplace in reloc.c and read the big
comment around its occurences.  Things are quite complicated when it comes
to relocation processing.

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."

Re: Problem with gdb relocation of debug info

[Daniel Jacobowitz]

On Sat, Jun 17, 2006 at 02:43:24PM +0200, Mattias Bertilsson wrote:
> ld -o [exe] [intermediate] -T [lcf] -n --emit-relocs -e [crt0] --cref 
> --discard-none -M

This is the key.

As Andreas said, gdb is doing the right thing.  But you don't want it
to do that right thing.  You might want to prevent GDB from applying
relocations in ET_EXEC files - I presume this produces an ET_EXEC file.

-- 
Daniel Jacobowitz
CodeSourcery