This is the mail archive of the
mailing list for the GCC project.
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>, "Joseph Myers (joseph at codesourcery dot com)" <joseph at codesourcery dot com>, "macro at codesourcery dot com" <macro at codesourcery dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "Moore, Catherine (Catherine_Moore at mentor dot com)" <Catherine_Moore at mentor dot com>
- Date: Fri, 14 Mar 2014 12:11:46 +0000
- Subject: RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534AAE6E at LEMAIL01 dot le dot imgtec dot org> <87mwhhg9e5 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AC1F0 at LEMAIL01 dot le dot imgtec dot org> <878ut0fj45 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AD16E at LEMAIL01 dot le dot imgtec dot org> <87ppmbdobm dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AEB92 at LEMAIL01 dot le dot imgtec dot org> <6D39441BF12EF246A7ABCE6654B023534B4C29 at LEMAIL01 dot le dot imgtec dot org> <87r46hbybi dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534B572B at LEMAIL01 dot le dot imgtec dot org> <87mwh5bslv dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534B581D at LEMAIL01 dot le dot imgtec dot org> <8761nsbj9w dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534B7B3A at LEMAIL01 dot le dot imgtec dot org> <871tygbexk dot fsf at talisman dot default> <87wqg89pvq dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534C0BEE at LEMAIL01 dot le dot imgtec dot org> <87y50dgkuh dot fsf at talisman dot default>
Richard Sandiford <email@example.com> writes:
> Matthew Fortune <Matthew.Fortune@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.