This is the mail archive of the gcc@gcc.gnu.org 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]

Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking


Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> The spec on:
> https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
> has been updated and attempts to account for all the feedback. Not
> everything has been possible to simplify/rework as requested but I
> believe I have managed to address many points cleanly.

(FWIW there seem to be some weird line breaks in the page which make
it a bit hard to read.)

The main thing that stood out for me was section 9.  If we have the
attributes and the program header (both good to have IMO) then we
shouldn't have an ELF flag too.  "Static" consumers should use the
attribute and "dynamic" consumers should use the program header.
The main point of encoding future info in a program header was to
relieve the pressure on the ELF flags.

As far as the program header encoding goes: I was thinking of a more
general mechanism that specifies a block of data, a bit like the current
PT_MIPS_OPTIONS does.  Encoding the information directly in the enumeration
wouldn't scale well, since we'd end up with the same problem as we have
now for ELF flags.  It would also be a bit wasteful to specify two bits
of information this way since the other parts of the header structure
don't carry any weight.

Thanks,
Richard


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