On Fri, Feb 25, 2000 at 04:53:17AM -0800, Ulf Carlsson wrote:
> I think have found the cause of the lost addend now. It's basically an
> attempt to fool bfd that backfires. The bfd thinks that local relocations
> always are relative to a section, and not relative to the section itself. The
> mips assembler code subtracts the value of the symbol from the relocation
> addend because it assumes that bfd will incorrectly add it back later, as it
> should have done if the relocation was relative to a section. However if the
> addend is 0, bfd assumes that it's a relocation against an external symbol,
> and thus drops the addend.
I think bfd has to explicitly check if the symbol is extern instead if I
understand you correctly?
> In our test case the symbol value is 8 and the
> relocation addend is 8 so we end up with 0 as the addend, and bfd doesn't add
> the symbol value back because it thinks the relocation is external. I don't
> see an obvious fix for this and there doesn't seem to be a generic workaround
> for it either, maybe I can find something tomorrow..
I've played with this variation of your code:
.data
.word 0
.globl foo
.align 2
.type foo,@object
.size foo,8
foo:
.word 0xdeadbeef
.word foo+4
and indeed looks like you are correct. I also took a look at elf32-mips.c.
It has a few places that check for if an addend is zero, just search for
->addend.
Ralf
|