This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: [PATCH] Only warn when missing MIPS LO16 are encountered
On 26 March 2007 17:19, H. J. Lu wrote:
> On Mon, Mar 26, 2007 at 04:53:56PM +0100, Thiemo Seufer wrote:
>> Paul Koning wrote:
>>>>>>>> "Thiemo" == Thiemo Seufer <ths@networkno.de> writes:
>>>
>>> Thiemo> Hello All, I applied the appended patch, it downgrades
>>> Thiemo> missing LO16 relocations from an error to a warning. This
>>> Thiemo> unbreaks builds with existing compilers but still gives gcc
>>> Thiemo> developers a better chance to find and fix the problematic
>>> Thiemo> bits in the optimizer.
>>>
>>> Warnings are still a problem when you're using the "warnings are
>>> errors" principle, as we and others do.
>>>
>>> Does this "missing" LO16 relocation cause any problem?
>>
>> It is a long-standing violation of the MIPS O32 ABI rules. It causes
>> unexpected cornercases for linker implementations (as seen here again)
>> but the resulting binaries run ok.
>>
>>> If not, why
>>> should there be a warning, and for that matter, why should this be
>>> called "problematic bits in the optimizer"?
>>
>> The optimizer should eliminate the whole HI/LO relocation pair.
>> Currently it doesn't do that in all cases.
>
> Can gas turn instruction with HI relocation without matching LO
> relocation into no-op?
Not without altering the program semantics, I would have thought. At the
moment, these can only arise through 1) faulty compiler 2) hand-coded
assembly. If we silently turn them into nops, we don't get any warning that
the compiler has emitted bad code. If the user has hand-coded one, they
probably have some idea what they mean by it, and would probably like the
assembler to interpret it according to least-surprise.
I think the sensible thing to do is just to treat unmatched HI16 as being
the equivalent of (addr & ~0xffff), i.e. assume that if there was a lo part,
it wouldn't carry into the high part.
cheers,
DaveK
--
Can't think of a witty .sigline today....