> Remember that support for %hi() and %lo() on REL targets is a GNU extension.
Erm. Are you sure?
SGI's ELF64 spec says:
"Any of the relocation types may appear in either a SHT_REL or a SHT_RELA
relocation section, except that relocation types involving AHL operands
are forbidden in a 64-bit SHT_REL section and discouraged in a 32-bit
SHT_REL section."
There is no word of GNU there and in any case SGI had their own tools. But
again, it is possible that the idea bounced back and forth...
> The assembler is expected to reorder the relocations so that the HI16s
> come before the LO16s. It sounds like this isn't happening in your case,
> so which version of binutils are you using?
The user who sent the b0rked binary (`K) uses 2.15.94 or so (I'll ask him
again) / "gcc 3.5". On 2.15 / gcc 3.4.3 there is no problem like this (at
least I can't trigger it).
> This isn't really a change from gcc 3.4 to "gcc 3.5" (now known as 4.0 ;).
Well, one of %hi()s is reordered to beginning of a loop and this is what
makes it unpaired. I don't think that any assembler could fix that.
Thanks for answering,
Stanislaw
|