[PATCH 1/2] Add support for O32 FPXX ABI

[Richard Sandiford]

Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> There is an open question about the use of program headers and exactly how
> this would work. The reasons for opting to use one program header (without a
> section) to specifically handle the O32 FPXX ABI are:

I still think this is a bad representation.

> 1) MIPS is running out of ELF flags.
> 2) ELF flags are not passed from kernel program loader to dynamic linker.
> 3) There are thousands of program header types available.
> 4) The indirection that would be required to obtain flag information if a
>    section were also involved is more complex than necessary.

As before, the indirection seems more complex when we just have one
piece of information we want to store.  But if we want to store other
things at a later stage, collecting it into a single structure could be
less complex then having to reassemble it from individual headers.

> 5) Program headers are only 32 bytes for 32-bit ELF and 64 bytes for 64-bit ELF
> 6) New features that require extra flags are not common and introducing further
>    program headers should not incur excessive cost. (Though it would be nice to
>    have more than 4 bits of processor specific flag data in a program header)

They don't seem that uncommon to me.  There are a few ASEs that don't
have ELF flags but probably should have.  I imagine they didn't get a
flag because there are so few left.  Also, we seem to be (ab?)using the
r2 ISA enumerations to mean r2-r5.  I imagine that if we had, say,
a 16-bit field to store the revision that we'd have used a straight
revision number instead.

So I certainly think we should design this on the assumption that we'll
need a few more pieces of information at some point.

I agree a 4-bit enumeration isn't good.  It certainly rules out being
able to use one program header like this to list all the ASEs in use.
We would presumably either have one header per ASE or group them arbitrarily
into groups of 4.

> 7) The (non)executable stack feature had similar requirements to the O32 FPXX
>    ABI and eventually opted for a specific program header. This seems like good
>    precedence albeit that PT_GNU_STACK is an architecture independent feature.

IMO PT_GNU_STACK is a “proper” segment.  It describes a region of memory
and is very similar to PT_GNU_RELRO.  The difference is of course that
PT_GNU_RELRO describes a region whose address and size are known at link
time while PT_GNU_STACK describes a region whose address and size are dynamic.

It looks to me like you're trying to use program headers like .dynamic tags
that apply to static executables as well as dynamic ones.  But to do that
you're having to shoehorn the payload into 4 bits of private flags,
which IMO just emphasises that this isn't the right representation.

This information is really like the load-time equivalent of .gnu_attributes.
.gnu_attributes collects the data into a single section and IMO the segment
side should too.

One representation would be to use the same data for the section and the
segment.  Or, if the attributes format seems too complicated for the loader,
we could add a simple pre-digested structure (with a version number as the
first field, say).

Thanks,
Richard