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

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Richard Sandiford <rdsandiford@googlemail.com> writes:
> 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.

Granted.
 
> > 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.

This is a bit subjective. We have an accumulation of features that lack
flags today but those features have appeared over several years at least.
Either way I do agree we shouldn't be forced to decide which features
deserve flags and which do not just because we have very few left.

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

OK.

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

Given that any new segment would need to be handled (in some ways) like
PT_NOTE then perhaps this does move the discussion towards PT_NOTE.
When I say it is like PT_NOTE I mean that the segment data would want 
to be stored as close to the program headers as possible to reduce the
amount of a file that needs to be read to check them. The cost of using
PT_NOTE would be the string comparison for the note name and the risk of
the notes being removed (I assume they can only be removed by specifically
doing so, at which point all bets are off anyway). I believe
notes have previously been rejected due to the string comparisons though:

http://sourceware.org/ml/binutils/2013-09/msg00099.html

Assuming we go for having a new program header and a segment to hold the
flags/structure... I could do with some pointers on how to go about
creating the segment, creating the header was relatively easy as I had
examples to go by but I can't see an example of creating a custom header
with a segment/data. I'm also unsure of how to get such data to be placed
close to the headers.

I've added Maciej and Joseph as I believe they have discussed this area
before.

Regards,
Matthew