> 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
