This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [patch] MIPS/ELF: %call_r/%got_r operators for relocation override
"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes:
> > Did you consider adding a new macro instead? Maybe something like
> > "lca" (for "load call address")? Reasons below.
>
> I fear a couple of macros would have to be added. But maybe only as few
> as three.
I have to admit I replied on the basis of the description of the patch,
assuming %call_r() was only supposed to apply to ld/dla. But I've just
downloaded your test case and see you added it for a lot more:
la dla jal lb lh lw ld lbu lhu lwu lwl lwr ll lld
lwc1 ldc1 ulh ulw uld sb sh sw swl sdl swr sdr
sc scd swc1 sdc1 ush usw usd
I can't really see a use for anything except la/dla:
- jal
Why would you need to use %got_r()? R_MIPS_CALL* will always be
implemented in the same way as R_MIPS_GOT* if lazy binding isn't
appropriate.
If you want to disable lazy binding for a particular call, you
can simply use a separate la/jalr. I imagine that's what most
people would use in practice since it would work with any
assembler.
- other loads (including ll, lld, lwc1, ldc1):
I don't see how R_MIPS_CALL* would be useful here. There's no
way of knowing whether the load will get the first byte of the
target function or the first byte of a stub.
- stores:
Same objection as loads. Also, functions ought to be in a
non-writable segment ;)
As I understand it, the only new functionality that you're adding
is a way to split:
jal foo
into something like:
...load address of foo into $25 using call relocs...
jalr $25
presumably in an attempt to schedule the load better. If so, I think
at most we want "lca" and "dlca" (or whatever you want to call them).
> Gcc is the easy part. It doesn't stricly emit what you quote, but:
>
> la $25,foo
> jalr reg,$25
>
> permitting any register for "reg" (for whatever reason).
Well, only in the sense that the return address wasn't checked by the
define_insn. All call insns did use $31 when they were first emitted.
If some pass changed that later, the code would simply not work.
There's no way for the user to say "this function expects the
incoming return address to be in $foo, not $31".
Richard