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
next 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