Richard Sandiford <rdsandif...@googlemail.com> writes: > Matthew Fortune <matthew.fort...@imgtec.com> writes: > > The spec on: > > https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinki > > ng 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.)
Apologies, I edited it offline and didn't check the result carefully enough. I'll clean it up. > 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. I know what you mean. I kept the ELF flag around because it firstly already exists (with the correct meaning as it happens) and secondly ELF flags are already consumed in the program loader whereas a small amount of new framework in the kernel is needed for the loader to respond to program headers. The 'executable stack' header is currently consumed but the mechanism is not extensible today. My thinking is that the ELF flag eases us into the program loader but could validly be dropped/not required long term. It is largely ignored by the tools anyway in favour of the program headers. I am happy to remove the ELF flag if I can confirm with our MIPS kernel developers that they can implement the program header inspection sooner rather than later. > 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. I was trying to avoid the need for a program header to refer to a block of data as that is another part of the object that has to be loaded to determine the flag information. There are 2^28 processor specific program headers available which seems quite generous (I half though of using 2 for the two modes), but I do also recognise that most of the header then becomes wasted space. I guess there may be some complaint if we choose to abuse every field of a header to encode information (i.e. address, size, alignment etc) but this would be a nice compact way to store flags. It would be more visible to put flags in the address fields as these are already printed by readelf et al. but the processor specific flags are not. Personally I'd open up all the fields to abuse over adding a block of data. The block of data increases the complexity of the program loader and dynamic loader as they have to ensure more of an object is read in order to make a decision. The extra data needed from an object would also be target specific, all do-able I'm just not sure on complexity. I wonder if Joseph or Maciej have any thoughts here as I believe they discussed this idea of using program headers in the past. Since I'm far from being an expert in this area I'm OK with anything as long as I can get all maintainers of dynamic loaders and program loaders to agree (ha!). Bionic, glibc, uclibc and linux kernel are the primary targets here. Regards, Matthew
