This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH RFA] fix generation of MIPS -membedded-pic jumps
At 07 Feb 2002 17:35:44 -0800, Eric Christopher wrote:
> > The code isn't the simplest, i agree.
> > if (value is not zero)
> > and ((not pcrel) or (this particular kind of pcrel reloc))
> > Previously, for fx_r_type == BFD_RELOC_16_PCREL_S2, this block won't
> > be executed, since (not pcrel) was false.
> > However, for that particular type of reloc, the block needs to be
> > executed. ("or at least, it does if we want the final link to produce
> > the correct output!" 8-)
> Right. Just makes me think that there's some other underlying problem
There's some earlier discussion in a thread starting at:
My understanding is that H.J.'s change which caused this problem to
crop up originally is "correct." (I.e., it has the intended result
and the intended result is desirable, minor bugs -- like this one --
occuring in its wake notwithstanding.)
To recap the whole problem, given a branch instruction like:
* if sym is undefined (external), that ends up being assembled as:
* if sym is defined in the file and local, it is assembled as:
b . + (sym - .text)
So, before H.J.'s change, if sym was defined in the file (global or
not) it was assembled the same as "defined in the file and local"
After H.J.'s change, branches/jumps to global symbols were no longer
relocated relative to the current section, but instead against the
However, for the case of embedded-pic and R_MIPS_GNU_REL16_S2, they
would be assembled as:
b . + (sym - .text)
and the result would be that (sym - .text) would end up being added
into the symbol twice. The linker would do (still does) the normal
processing for a relocation against a symbol, and the addition of the
(sym - .text) in the instruction doubled that offset.
Needless to say, that was detrimental to correct operation of the
resulting code. 8-)
The patch I supplied causes that sequence to be assembled as:
i.e., the same as relocations against other symbols.
It could very well be that my patch is not correct, and that The Right
Thing would cause that extra offset to be removed at a different place
in the assembler.
However, at the time (and we've been running with a patch very similar
to this since around 2001-07-26, so i forget what might have led me to
the conclusion), this looked like the right place. 8-)