This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] MIPS: Incorrect calculation for R_MIPS_LO16 relocs


"Maciej W. Rozycki" <macro@linux-mips.org> writes:
>  Still I don't think a marginal breakage is better than a common one.  It
> may actually be the reverse -- if everything breaks, you immediately
> notice something's wrong.  If things break ocassionally, they may stay
> unnoticed until they hit badly and you don't really know why.  And you
> won't find out unless you are skilled enough to find the offending place,
> disassemble it and compare with sources.

But who's disputing that?  No-one's saying that the bug shouldn't
be fixed. ;)  It's just a question of how.

>> >  And gcc 3.4 is out for how long?  Two months.  Do you think all the 
>> > people rushed out to rebuild all their binaries with a new release?  I 
>> > don't.
>> 
>> I'm not sure where you get the idea that this is specific to 3.4.
> [...]
>> with a 3.3 mips64-elf compiler using "-O2 -G0".  I get the attached code.
>
>  I wasn't aware explicit relocs were introduced before 3.4.  This fact of 
> course invalidates my claim.

Just for the record: full explicit reloc support (as controlled by
-mexplicit-relocs) _is_ new to 3.4.  But gcc has been able to use
%hi() and %lo() for many years.  Certainly as far back as 2.95.

This limited form of explicit reloc support was controlled by
-msplit-addresses and was enabled by default when optimising
and using gas.  According to the changelogs, it was added to
public gcc sources in April 1997.

>> This might work, but ugh!  It doesn't appeal to me at all.  Maybe the
>> maintainers will feel differently though...
>
>  Hmm, have you expected anything nice?

;)

> I'm afraid there are not many options and given two ugly solutions I'd
> select one that gives the correct output plus an opportunity to clean
> up the mess sometime in the future (hint, hint).

Agreed that we have a choice between two ugly solutions.  I still
think there are arguments in favour of the ugly gas patch though.

The main one is that it leaves the door open to accurate warnings.
In other words: as a separate patch, we could get the linker to warn
about _all_ high-part relocations against mergeable section symbols
in which the high-part offset is nonzero.  This will catch existing
objects that are susceptible to the bug while giving very few false
positives.

In contrast, with your patch, we would have a legitimate use for
such relocations, so we couldn't easily tell whether the object
is faulty or not.  (This is the point you made in (3) in your
earlier mail.)  And the number of false positives would be high,
since we would warn about 16-bit offsets that the old linker
would have handled correctly.

Richard

BTW, if we go for the new interpretation of LO16 relocs, are you
that sure only _bfd_mips_elf_relocate_section needs changing?
What about the howto functions?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]