> I think bfd has to explicitly check if the symbol is extern instead if I
> understand you correctly?
The issue has obviously been solved in the i386 code since they have extern or
weak local relocations against the symbols themselves and not as an offset
from the section. I took a quick look at the i386 code last night, but it
seems to have a lot of differences from what we're doing in the MIPS code
right now. I think we can convert the technique they're using for their
relocations though, we're basically trying to do the same thing. I didn't
really find how they do it in the i386 code but they may set the section for
weak and global symbols to something else than the common section and thus
they don't get into the stupid nutcase when the bfd assumes that the
relocation is against the section itself.
> > 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:
Yeah, it was possible to simplify the testcase a little bit...
> 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.
Well, it doesn't matter what addends we pass to the bfd interface it will
still break unless we do something serious about it. It is not possibly to
tell the bfd to generate a relocation to a symbol with offset equal to the
addend. We shouldn't have to do something special for the addend is equal to
zero case, we need a generic solution.
Anyway we aren't really in a hurry to fix this right now, it's easy to provide
a workaround for this specific case in the kernel. I'll try to fix it over
the weekend.
Ulf
|