Problem with gdb relocation of debug info

Mattias Bertilsson mattias.bertilsson@enea.com
Sat Jun 17 13:14:00 GMT 2006


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



More information about the Binutils mailing list