This is the mail archive of the mailing list for the GCC 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]

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

[sorry for the resend, I goofed the gcc@ mailing list address the first time.]

(Added GCC list, and changed subject.  8-)

OK, looks like the summary here is:

* MIPS pc-relative 32-bit and 64-bit relocs were embedded-PIC
  extensions, and I removed them from binutils per dicussions on the
  binutils list.

* 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)

* no matter what's done w.r.t. GCC's representation of the EH data,
  binutils post 2.15 should continue to support 32-bit pc-relative
  relocs for "a while" to support use of new versions of binutils with
  "old" versions of GCC (incl. 3.4.x).

  (Ideally, GCC 3.4.1 would be modified to use the appropriate
  representation for EH data for both mips- and mips64-linux
  compilers, but I would understand if this is not possible.)

* there's some question (at least in my mind, still) about what the
  Right Thing for GCC to do here is:

        * the pc-relative 32-bit and 64-bit relocs are GNU extensions
          that were added for embedded-PIC support.  They are

        * *not* using pc-relative relocs would, I believe, be less
          efficient (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).

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

        * 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."

        * Questions:

                * Is there a real efficiency issue here?

                * 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.)

                * 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-)

so, thoughts?

I probably won't be able to do much work to fix binutils before
Monday.  (If somebody else wants to take a crack at it, that's fine w/
me.  8-)


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