Home Original page

[PATCH] Only warn when missing MIPS LO16 are encountered

Richard Sandiford richard@codesourcery.com
Tue Mar 27 21:09:00 GMT 2007 
"Dave Korn" <dave.korn@artimi.com> writes:
> 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.

The problem is, %hi16 without %lo16 has no defined semantics,
so there aren't really any semantics to change.  I don't think...

> 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.

...hand-coding an orphaned %hi16 is really a reasonable thing to do.

How about HJ's suggestion?  Would there be any problem with getting
gas to drop orphaned %hi16s, with an appropriate warning?  (And doing
it in addition to whatever the linker eventually does?)  The warning
could be under option control, so it could be turned off by -Werror
users.  FWIW, I think warning in the assembler would help gcc testers,
because it would also pick up problems in non-link tests.

Richard
More information about the Binutils mailing list