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]

Re: 2.10.91: A problem with R_MIPS_CALL relocations within gas


On Tue, 21 Nov 2000, Hiroyuki Machida wrote:

> >  You are right.  Do we have any means to detect the common sequence of "la
> > $25, <sym>", "jalr $25" then?  We could use that to decide to emit CALL
> > relocations unconditionally when we have no information from gcc (or other
> > compiler).
> 
> I guess we have three ways...
> 
> 1. Change GCC to emit jal <symbol> if target is GAS and PIC.
>    This is the easist way, but we lose the opportunity to optimize
>    as Ian pointed out.

 Agreed.  We'd better avoid it.

> 2. Make new macro like "la_lazy" to inform lazy-bind-able symbol to GAS.
>    Change GCC and GAS to use it. This chage is not so hard. But in
>    this way, we have to chage both GCC and GAS at the same time.  
>    I don't know everyone accept such a kind of change. 

 This sounds feasible.  But maybe it would be better to define and use new
operators, such as "%call", "%call_hi" and "%call_lo".  We could apply
CALL relocs to any opcodes then and the syntax would be coherent.  And we
need not change both programs at once -- we might change GCC later.

> 3. Change GAS to track t9 register and detect lazy-bind-able.
>    This change can be harder than aboves.

 This surely might be an option but we'd have to decide how much to track
t9.  I suggested a simple approach, when we'd only look for the common
sequence of "la $25, <sym>", "jalr $25".  This would be sufficient, at
least for now, I believe, as GOT relocs are not incorrect in this context,
just less optimal.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


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