Matthew Fortune <matthew.fort...@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
