Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mattias Bertilsson <mattias.bertilsson@enea.com>
To: gdb@sourceware.org,  binutils@sourceware.org
Subject: Problem with gdb relocation of debug info
Date: Sat, 17 Jun 2006 13:14:00 -0000	[thread overview]
Message-ID: <4493F8EC.8040106@enea.com> (raw)

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


             reply	other threads:[~2006-06-17 12:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-17 13:14 Mattias Bertilsson [this message]
2006-06-17 15:35 ` Andreas Schwab
     [not found]   ` <4494179C.9010401@enea.com>
2006-06-17 18:47     ` Andreas Schwab
2006-06-20 12:37 ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4493F8EC.8040106@enea.com \
    --to=mattias.bertilsson@enea.com \
    --cc=binutils@sourceware.org \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox