From: Andreas Schwab <schwab@suse.de>
To: Mattias Bertilsson <mattias.bertilsson@enea.com>
Cc: gdb@sourceware.org, binutils@sourceware.org
Subject: Re: Problem with gdb relocation of debug info
Date: Sat, 17 Jun 2006 15:35:00 -0000 [thread overview]
Message-ID: <jeirmz3owo.fsf@sykes.suse.de> (raw)
In-Reply-To: <4493F8EC.8040106@enea.com> (Mattias Bertilsson's message of "Sat, 17 Jun 2006 14:43:24 +0200")
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."
next prev parent reply other threads:[~2006-06-17 13:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-17 13:14 Mattias Bertilsson
2006-06-17 15:35 ` Andreas Schwab [this message]
[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=jeirmz3owo.fsf@sykes.suse.de \
--to=schwab@suse.de \
--cc=binutils@sourceware.org \
--cc=gdb@sourceware.org \
--cc=mattias.bertilsson@enea.com \
/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