Resend: GAS embedded-PIC reloc removal vs. mips-linux exception handling

[Alexandre Oliva]

On May  6, 2004, cgd@broadcom.com wrote:

> * mips-linux uses the 32-bit pc-relative extensions to represent
>   exception handling info.  mips64-linux *does not*, even for o32.  (I
>   tested the latter only, thinking that surely there would be no
>   difference for o32!  8-)

>   (see ASM_PREFERRED_EH_DATA_FORMAT in config/mips/linux*.h)

I suppose this was my mistake, or maybe I was just trying to avoid
relying on non-standard relocations and forgot to keep them in sync.
Or maybe they were changed again.  Can't remember, sorry.

>         * *not* using pc-relative relocs would, I believe, be less
>           efficient

Using GP-relative relocations would be just as efficient, and I think
those are standard.  It just takes a bit of implementation work to
arrange for datarel encoding to mean GP-relative everywhere.

>           (esp. for things like shlibs/PIE, which can be relocated
>           -- but I don't know if this is truly an issue since I
>           don't know how EH data needs to be used/relocated).

If there are relocations there, they have to be applied at the same
time as every other dynamic relocation in the binary (other than
JMPREL, that get applied at the first time the corresponding PLT entry
is called)

That said, dynamic relocations on MIPS tend to be very simple: they're
relative, so they aren't very expensive to apply.  But they still
force pages to be unshared, which is not ideal, so we'd rather avoid
relocations in exception handling tables.

>         * To my mind, using non-standard relocs should be avoided if
>           possible.

Agreed.

>         * Efficiency is better than inefficiency, and pc-relative
>           32-bit and 64-bit relocs have fairly easily understood
>           meanings, so keeping and continuing to rely on the extension
>           may be "OK."

If we can switch to GP-relative relocations, we get the best of both
worlds.  Assuming there are suitable GP-relative relocations, of
course.  It's been a while, I no longer have the details off the top
of my head.


Summary:

>                 * Is there a real efficiency issue here?

Yup.  We'd like to avoid having to apply dynamic relocations in EH
tables every time the shared lib is loaded, because it's
potentially-wasted CPU processing, as well as wasted memory in case
the pages could have remained shared with other processes.

>                 * If so, could other mechanisms in the EH data be used
>                   to avoid this inefficiency?  (would use of
>                   DW_EH_PE_{text,data}rel be adequate?  They seem to
>                   be used for this purpose on ia64.)

Yeah, datarel is enough.  We could use textrel, but then we'd have to
define a text base pointer, and we don't really need one.

>                 * If doing something here other than just
>                   DW_EH_PE_absptr (the default, currently used by
>                   mips64-linux AFAICT), one probably should use 64-bit
>                   relocs for 64 (like ia64 does), unless using
>                   PC-relative and we're OK declaring a 32-bit size
>                   limit on shlibs/PIEs.  8-)

Yup.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}