Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes: > Richard Sandiford writes: >> Matthew Fortune writes: >> > Richard Sandiford writes: >> >> Matthew Fortune writes: >> >> > As it stands I wasn't planning on supporting .module arch= I was >> >> > just going to add .module fp= and leave it at that. The only thing >> >> > I need to give assembly code writers absolute control over is the >> >> > overall FP mode of the module. I don't currently see any real need >> >> > to increase the control a user has over architecture level. If we >> >> > had .module arch= then having it just set the arch ignorant of FP >> >> > mode seems fine, checking for erroneous combinations would be >> >> > difficult due to some chicken and egg scenarios. Do you think I >> >> > need to add .module arch= if I add .module fp= or can I take the >> easy option? >> >> >> >> Despite the "arch controlling fp" difference, I think .set and >> >> .module should use common parsing code. I.e. we should generalise >> >> s_mipsset to handle both of them rather than write a second parsing >> >> function for .module. >> >> There will be some cases where the function has to check "is this >> .set?" >> >> (e.g. push/pop), but that's good IMO, because it makes the >> >> differences obvious. >> >> >> >> If we do have a common routine then we should make .module handle >> >> everything it can handle rather than just fp=. >> > >> > Every case would need to look at set vs module as .set writes to >> > mips_opts and .module writes to things like file_mips_arch? I suppose >> > I could just rework all the global options to be part of a single >> > mips_set_options structure to abstract this. Does that sound OK? >> >> Yeah, that's the kind of thing I was thinking of. FWIW, if this is >> feeling like feature creep then I have a go this weekend. > > Although it does seem like feature creep, I'm happy to do it as it gives > a smaller problem for me to work on and submit to go through the > motions. It may however be worthwhile tying this in with the > introduction of -mfpxx to allow one assembler feature test to infer that > both the new .module support and fpxx are implemented (or would you do > this as two tests anyway?). Yeah, .module should be a different configure test. I don't think we need an fpxx test though. We don't usually do configure checks for passed-down -m* options since it's really the assembler's job to say what it accepts. It also means users can upgrade binutils without rebuilding GCC. We only need configure tests (like .module) for optional enhancements that get used under the covers. >> > The push/pop case (and perhaps some others) will still need special >> > handling to prohibit them for .module. >> >> Right. But like I say, that's good IMO, since the differences become >> more obvious than they'd be with two different implementations. >> >> > Back to one of your questions discussing things like: >> > >> > .module fp=xx >> > .module arch=mips2 >> > >> > An easy option would be to continue to have the arch options infer >> > fp32 or fp64 and require the .module fp=xx to come second. Then we >> > just have error checking on the .module fp= option to ensure it is >> > suitable for use with the previously specified architecture. >> >> I don't think it's a good idea for the order of the .modules to matter. >> I think as far as possible, putting .module in the code should be the >> same as passing the associated command-line option. >> >> It probably makes sense to prohibit .module after an instruction has >> been assembled or after .set has been seen. We could then handle the >> .module-adjusted options at those points (or at the end, if there are no >> .sets and no instructions). >> >> > With .module in place like this then I expect the compiler should then >> > start to record more information in the assembly text to indicate >> > things like arch as well as fp. Obviously this will be tied to a >> > configure time assembler feature test. >> >> Agreed. > > Fantastic. I think the only loose end is: > http://gcc.gnu.org/ml/gcc/2014-03/msg00204.html > > I'm concerned about the program loader and dynamic linker having to read > a segment as well as the header to get the feature bits when the program > header fields could be interpreted specially for a new program header > type. With 7 32-bit fields there are 224 bits of data available which > seems quite generous and would be simple to read. As it stands ld.so > carries around a pointer to and quantity of the program headers which > means the data directly present in the headers is exceptionally easy to > read, a segment is harder. (I hope I have the right terminology there > with 'segment'). Like you say, it'd be good to hear other people's thoughts. I think in practice a loader is going to have a reasonable interface for accessing a given segment, so it should just be a setup call, some error checking, and a tear-down call. The advantage of encoding it directly in header types is that it avoids ha
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford writes: > Matthew Fortune writes: > > Richard Sandiford writes: > >> Matthew Fortune writes: > >> > As it stands I wasn't planning on supporting .module arch= I was > >> > just going to add .module fp= and leave it at that. The only thing > >> > I need to give assembly code writers absolute control over is the > >> > overall FP mode of the module. I don't currently see any real need > >> > to increase the control a user has over architecture level. If we > >> > had .module arch= then having it just set the arch ignorant of FP > >> > mode seems fine, checking for erroneous combinations would be > >> > difficult due to some chicken and egg scenarios. Do you think I > >> > need to add .module arch= if I add .module fp= or can I take the > easy option? > >> > >> Despite the "arch controlling fp" difference, I think .set and > >> .module should use common parsing code. I.e. we should generalise > >> s_mipsset to handle both of them rather than write a second parsing > >> function for .module. > >> There will be some cases where the function has to check "is this > .set?" > >> (e.g. push/pop), but that's good IMO, because it makes the > >> differences obvious. > >> > >> If we do have a common routine then we should make .module handle > >> everything it can handle rather than just fp=. > > > > Every case would need to look at set vs module as .set writes to > > mips_opts and .module writes to things like file_mips_arch? I suppose > > I could just rework all the global options to be part of a single > > mips_set_options structure to abstract this. Does that sound OK? > > Yeah, that's the kind of thing I was thinking of. FWIW, if this is > feeling like feature creep then I have a go this weekend. Although it does seem like feature creep, I'm happy to do it as it gives a smaller problem for me to work on and submit to go through the motions. It may however be worthwhile tying this in with the introduction of -mfpxx to allow one assembler feature test to infer that both the new .module support and fpxx are implemented (or would you do this as two tests anyway?). > > The push/pop case (and perhaps some others) will still need special > > handling to prohibit them for .module. > > Right. But like I say, that's good IMO, since the differences become > more obvious than they'd be with two different implementations. > > > Back to one of your questions discussing things like: > > > > .module fp=xx > > .module arch=mips2 > > > > An easy option would be to continue to have the arch options infer > > fp32 or fp64 and require the .module fp=xx to come second. Then we > > just have error checking on the .module fp= option to ensure it is > > suitable for use with the previously specified architecture. > > I don't think it's a good idea for the order of the .modules to matter. > I think as far as possible, putting .module in the code should be the > same as passing the associated command-line option. > > It probably makes sense to prohibit .module after an instruction has > been assembled or after .set has been seen. We could then handle the > .module-adjusted options at those points (or at the end, if there are no > .sets and no instructions). > > > With .module in place like this then I expect the compiler should then > > start to record more information in the assembly text to indicate > > things like arch as well as fp. Obviously this will be tied to a > > configure time assembler feature test. > > Agreed. Fantastic. I think the only loose end is: http://gcc.gnu.org/ml/gcc/2014-03/msg00204.html I'm concerned about the program loader and dynamic linker having to read a segment as well as the header to get the feature bits when the program header fields could be interpreted specially for a new program header type. With 7 32-bit fields there are 224 bits of data available which seems quite generous and would be simple to read. As it stands ld.so carries around a pointer to and quantity of the program headers which means the data directly present in the headers is exceptionally easy to read, a segment is harder. (I hope I have the right terminology there with 'segment'). Regards, Matthew
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes: > Richard Sandiford writes: >> Matthew Fortune writes: >> > As it stands I wasn't planning on supporting .module arch= I was just >> > going to add .module fp= and leave it at that. The only thing I need >> > to give assembly code writers absolute control over is the overall FP >> > mode of the module. I don't currently see any real need to increase >> > the control a user has over architecture level. If we had .module >> > arch= then having it just set the arch ignorant of FP mode seems fine, >> > checking for erroneous combinations would be difficult due to some >> > chicken and egg scenarios. Do you think I need to add .module arch= if >> > I add .module fp= or can I take the easy option? >> >> Despite the "arch controlling fp" difference, I think .set and .module >> should use common parsing code. I.e. we should generalise s_mipsset to >> handle both of them rather than write a second parsing function for >> .module. >> There will be some cases where the function has to check "is this .set?" >> (e.g. push/pop), but that's good IMO, because it makes the differences >> obvious. >> >> If we do have a common routine then we should make .module handle >> everything it can handle rather than just fp=. > > Every case would need to look at set vs module as .set writes to > mips_opts and .module writes to things like file_mips_arch? I suppose I > could just rework all the global options to be part of a single > mips_set_options structure to abstract this. Does that sound OK? Yeah, that's the kind of thing I was thinking of. FWIW, if this is feeling like feature creep then I have a go this weekend. > The push/pop case (and perhaps some others) will still need special > handling to prohibit them for .module. Right. But like I say, that's good IMO, since the differences become more obvious than they'd be with two different implementations. > Back to one of your questions discussing things like: > > .module fp=xx > .module arch=mips2 > > An easy option would be to continue to have the arch options infer fp32 > or fp64 and require the .module fp=xx to come second. Then we just have > error checking on the .module fp= option to ensure it is suitable for > use with the previously specified architecture. I don't think it's a good idea for the order of the .modules to matter. I think as far as possible, putting .module in the code should be the same as passing the associated command-line option. It probably makes sense to prohibit .module after an instruction has been assembled or after .set has been seen. We could then handle the .module-adjusted options at those points (or at the end, if there are no .sets and no instructions). > With .module in place like this then I expect the compiler should then > start to record more information in the assembly text to indicate things > like arch as well as fp. Obviously this will be tied to a configure time > assembler feature test. Agreed. Thanks, Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford writes: > Matthew Fortune writes: > > As it stands I wasn't planning on supporting .module arch= I was just > > going to add .module fp= and leave it at that. The only thing I need > > to give assembly code writers absolute control over is the overall FP > > mode of the module. I don't currently see any real need to increase > > the control a user has over architecture level. If we had .module > > arch= then having it just set the arch ignorant of FP mode seems fine, > > checking for erroneous combinations would be difficult due to some > > chicken and egg scenarios. Do you think I need to add .module arch= if > > I add .module fp= or can I take the easy option? > > Despite the "arch controlling fp" difference, I think .set and .module > should use common parsing code. I.e. we should generalise s_mipsset to > handle both of them rather than write a second parsing function for > .module. > There will be some cases where the function has to check "is this .set?" > (e.g. push/pop), but that's good IMO, because it makes the differences > obvious. > > If we do have a common routine then we should make .module handle > everything it can handle rather than just fp=. Every case would need to look at set vs module as .set writes to mips_opts and .module writes to things like file_mips_arch? I suppose I could just rework all the global options to be part of a single mips_set_options structure to abstract this. Does that sound OK? The push/pop case (and perhaps some others) will still need special handling to prohibit them for .module. Back to one of your questions discussing things like: .module fp=xx .module arch=mips2 An easy option would be to continue to have the arch options infer fp32 or fp64 and require the .module fp=xx to come second. Then we just have error checking on the .module fp= option to ensure it is suitable for use with the previously specified architecture. With .module in place like this then I expect the compiler should then start to record more information in the assembly text to indicate things like arch as well as fp. Obviously this will be tied to a configure time assembler feature test. Regards, Matthew
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes: > As it stands I wasn't planning on supporting .module arch= I was just > going to add .module fp= and leave it at that. The only thing I need to > give assembly code writers absolute control over is the overall FP mode > of the module. I don't currently see any real need to increase the > control a user has over architecture level. If we had .module arch= then > having it just set the arch ignorant of FP mode seems fine, checking for > erroneous combinations would be difficult due to some chicken and egg > scenarios. Do you think I need to add .module arch= if I add .module fp= > or can I take the easy option? Despite the "arch controlling fp" difference, I think .set and .module should use common parsing code. I.e. we should generalise s_mipsset to handle both of them rather than write a second parsing function for .module. There will be some cases where the function has to check "is this .set?" (e.g. push/pop), but that's good IMO, because it makes the differences obvious. If we do have a common routine then we should make .module handle everything it can handle rather than just fp=. Thanks, Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford writes: > Matthew Fortune writes: > >> > With these defaults, the closest supported ABI is used for each > >> > architecture based on the --with-o32-fp build option. The only one > >> > I really care about is the middle one as it makes full use of the > >> > O32 FPXX ABI without a user needing to account for arch > restrictions. > >> > >> Note that --with-* options just insert a canned -mfoo=bar option > >> under certain conditions, with those conditions being the same > >> regardless of "bar". > >> So --with-o32-fp=32 should insert -mfp32 (and nothing else), > >> --with-o32- > >> fp=64 should insert -mfp64, etc. > >> > >> The rules should therefore be the same for both -mfp and --with-o32- > fp. > >> Should: > >> > >> mips-*-gcc -march=mips1 -mfpxx > >> > >> generate -mfp32 code too? It seems counter-intuitive to me. > >> > >> I suppose it depends on what you want -mfpxx to mean. Do you want it > >> to mean "use the new ABI that is link-compatible with both -mfp32 and > >> - mfp64" > >> or do you want it to mean "I don't care what the FR setting is; pick > >> whatever seems best but be as flexible as possible"? I'd assumed the > >> former, in which case using it with an architecture that doesn't > >> support it should be an error. > > > > In the end I do just want fpxx to mean use the new ABI that is > > link-compatible. I think I have managed to confuse this discussion by > > not understanding/separating vendor specific specs from generic option > > handling as you explain later in your email. I only really wish to > > allow a vendor specific config to infer a suitable default fp option > > from -march (like -mabi=32 for 32-bit arch and -mabi=n32 for 64-bit > arch). > > Well, for avoidance of doubt, --with has priority over the vendor- > specific choices, so really this comes down to what happens when no -mfp > and --with-o32-fp options are used. Yes that is what I understood. > >> If you want to go for tha latter meaning then I think we should be > >> careful to distinguish it from cases where we really are talking > >> about the new ABI variant. E.g. an ELF file has to commit to one of > >> the three > >> modes: you shouldn't have to look at the ELF's architecture setting > >> in order to interpret the FP setting correctly. And IMO the assembly > >> code needs to commit to a specific mode too. What do you think > >> should happen > >> for: > >> > >> .module fp=xx > >> .module arch=mips_n > >> > >> Should the output be FR=X or FR=1? > > > > Well, even defining fpxx as simply being another abi variant there are > > some issues. The current .set arch= options set fp32 for 32-bit > > architectures and fp64 for 64-bit architectures which means we do have > > to come up with some definition of how fpxx interacts with this. My > > current implementation is that, for .set arch, the fp option is only > > changed if the existing setting is incompatible with the new arch. So > > carrying that logic to .module means that in the case above then the > > output would be FPXX. Other examples would then be: > > > > .module fp=xx > > .module arch=mips_n > > > > .module fp=32 > > .module arch=mips_n > > > > > > .module fp=xx > > .module arch=mips2 > > > > .module fp=64 > > .module arch=mips2 > > (existing behaviour for .set) > > > > .module fp=xx > > .module arch=mips1 > > > > .module fp=64 > > .module arch=mips1 > > (existing behaviour for .set) > > > > This is weird though for the same reasons as you point out. You have > > to know the arch to know what happens to the FP mode. If we just > > continued with 32-bit arch setting fp=32 and 64-bit setting fp=64 then > > we have a problem with something like mips_n where fp=32 would be > > invalid. I really don't know what is best here! > > The ".set mips" handling of gp and fp is really there for local changes > to the architecture in a .set push/pop or .set mipsN/mips0. (And IMO we > the way we do it is a bit of a misfeature, but we have to keep it that > way for compatibility.) > > I don't think it should apply to .module though. Ideally .module should > work in the same way as passing the associated command-line option. As it stands I wasn't planning on supporting .module arch= I was just going to add .module fp= and leave it at that. The only thing I need to give assembly code writers absolute control over is the overall FP mode of the module. I don't currently see any real need to increase the control a user has over architecture level. If we had .module arch= then having it just set the arch ignorant of FP mode seems fine, checking for erroneous combinations would be difficult due to some chicken and egg scenarios. Do you think I need to add .module arch= if I add .module fp= or can I take the easy option? Regards, Matthew
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes: >> > With these defaults, the closest supported ABI is used for each >> > architecture based on the --with-o32-fp build option. The only one I >> > really care about is the middle one as it makes full use of the O32 >> > FPXX ABI without a user needing to account for arch restrictions. >> >> Note that --with-* options just insert a canned -mfoo=bar option under >> certain conditions, with those conditions being the same regardless of >> "bar". >> So --with-o32-fp=32 should insert -mfp32 (and nothing else), --with-o32- >> fp=64 should insert -mfp64, etc. >> >> The rules should therefore be the same for both -mfp and --with-o32-fp. >> Should: >> >> mips-*-gcc -march=mips1 -mfpxx >> >> generate -mfp32 code too? It seems counter-intuitive to me. >> >> I suppose it depends on what you want -mfpxx to mean. Do you want it to >> mean "use the new ABI that is link-compatible with both -mfp32 and - >> mfp64" >> or do you want it to mean "I don't care what the FR setting is; pick >> whatever seems best but be as flexible as possible"? I'd assumed the >> former, in which case using it with an architecture that doesn't support >> it should be an error. > > In the end I do just want fpxx to mean use the new ABI that is > link-compatible. I think I have managed to confuse this discussion by > not understanding/separating vendor specific specs from generic option > handling as you explain later in your email. I only really wish to allow > a vendor specific config to infer a suitable default fp option from > -march (like -mabi=32 for 32-bit arch and -mabi=n32 for 64-bit arch). Well, for avoidance of doubt, --with has priority over the vendor-specific choices, so really this comes down to what happens when no -mfp and --with-o32-fp options are used. >> If you want to go for tha latter meaning then I think we should be >> careful to distinguish it from cases where we really are talking about >> the new ABI variant. E.g. an ELF file has to commit to one of the three >> modes: you shouldn't have to look at the ELF's architecture setting in >> order to interpret the FP setting correctly. And IMO the assembly code >> needs to commit to a specific mode too. What do you think should happen >> for: >> >> .module fp=xx >> .module arch=mips_n >> >> Should the output be FR=X or FR=1? > > Well, even defining fpxx as simply being another abi variant there are > some issues. The current .set arch= options set fp32 for 32-bit > architectures and fp64 for 64-bit architectures which means we do have > to come up with some definition of how fpxx interacts with this. My > current implementation is that, for .set arch, the fp option is only > changed if the existing setting is incompatible with the new arch. So > carrying that logic to .module means that in the case above then the > output would be FPXX. Other examples would then be: > > .module fp=xx > .module arch=mips_n > > .module fp=32 > .module arch=mips_n > > > .module fp=xx > .module arch=mips2 > > .module fp=64 > .module arch=mips2 > (existing behaviour for .set) > > .module fp=xx > .module arch=mips1 > > .module fp=64 > .module arch=mips1 > (existing behaviour for .set) > > This is weird though for the same reasons as you point out. You have to > know the arch to know what happens to the FP mode. If we just continued > with 32-bit arch setting fp=32 and 64-bit setting fp=64 then we have a > problem with something like mips_n where fp=32 would be invalid. I > really don't know what is best here! The ".set mips" handling of gp and fp is really there for local changes to the architecture in a .set push/pop or .set mipsN/mips0. (And IMO we the way we do it is a bit of a misfeature, but we have to keep it that way for compatibility.) I don't think it should apply to .module though. Ideally .module should work in the same way as passing the associated command-line option. Thanks, Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford writes:
> Matthew Fortune writes:
> > Richard Sandiford writes:
> >> Matthew Fortune writes:
> >> >> I think instead we should have a configuration switch that allows
> >> >> a particular -mfp option to be inserted alongside -mabi=32 if no
> >> >> explicit -mfp is given. This is how most --with options work.
> >> >> Maybe
> >> >> --with-fp- 32={32|64|xx}? Specific triples could set a default
> >> >> value
> >> if they like.
> >> >> E.g. the MTI, SDE and mipsisa* ones would probably want to default
> >> >> to
> >> >> -- with-32-fp=xx. Triples aimed at MIPS IV and below would stay
> >> >> as they are. (MIPS IV is sometimes used with -mabi=32.)
> >> >>
> >> >> --with-fp-32 isn't the greatest name but is at least consistent
> >> >> with
> >> >> --with-arch-32 and -mabi=32. Maybe --with-fp-32=64 is so weird
> >> >> that breaking consistency is better though.
> >> >
> >> > Tying the use of fpxx by default to a configure time setting is OK
> >> > with me. When enabled it would still have to follow the rules as
> >> > defined in the design in that it can only apply to architectures
> >> > that can support the variant.
> >>
> >> Right. It's really equivalent to putting the -mfp on every command
> >> line that doesn't have one.
> >>
> >> > Currently that means everything but mips1.
> >>
> >> Yeah, using -mips1 on a --with-{o}32-fp=xx toolchain would be an
> error.
> >>
> >> > I'm not sure this is the same as tying an ABI to an architecture as
> >> > both fp32 and fpxx are O32 and link compatible. Perhaps the
> >> > configure switch would be --with-o32-fp={32|64|xx}. This shows it
> >> > is just an O32 related setting.
> >>
> >> What I meant is that -march= and -mips shouldn't imply a different
> >> -mfp setting. The -mfp setting should be self-contained and it
> >> should be an error if the architecture isn't compatible.
> >>
> >> We might be in violent agreement here :-) Like I say, I was just a
> >> bit worried by the earlier -mips32r2 thing because there was a time
> >> when a - mips option really could imply things like -mabi, -mgp and -
> mfp.
> >>
> >> --with-o32-fp would be OK with me. I'm just worried about the ABI
> >> being spelt differently from -mabi=, but there's probably no perfect
> >> alternative.
> >
> > I'd like to encourage the perspective that -mfp* options do not lead
> > to a different ABI in the same sense that other variations do. While
> > it is true that the calling conventions and code generation rules
> > vary, 2 out of 3 combinations of -mfp32 -mfpxx and -mfp64 with
> > -mabi=o32 are link compatible.
>
> -mfp32 and -mfp64 aren't link-compatible though, so -mfp is part of the
> ABI.
> What you're adding is a new variant that is individually link-compatible
> with the other two (but obviously not both simultaneously). It's a
> third ABI variant in itself.
>
> > The introduction of the modeless O32 ABI is intended to remove the
> > part of the O32 definition that says 'FR=0' and hence the architecture
> > then gets to dictate this and the generated code is still O32. It is
> > true today that we have several architectures that mandate FR=0, some
> > that cannot support fpxx and some that can support all fp* variations.
> > I see nothing preventing the future having an architecture only
> > supporting FR=1 though which we should also think about.
>
> Agreed.
>
> > When considering such a scenario it would be highly desirable for the
> > following to just work as I believe architectural restrictions should
> > be accounted for when designing default options. If the architecture
> > gives no choice then it should just work IMO:
> >
> > Some ideas (speculating that someone builds a core called mips_n with
> > only FR=1):
> >
> > --with-o32-fp=32
> >
> > mips-*-gcc -march=mips1 fp.c ==> generates fp32 code mips-*-gcc
> > -march=mips2 fp.c ==> generates fp32 code mips-*-gcc -march=mips32r2
> > fp.c ==> generates fp32 code mips-*-gcc -march=mips32r2 -mfp64 fp.c
> > ==> generates fp64 code mips-*-gcc -march=mips_n fp.c ==> generates
> > fp64 code
> >
> > --with-o32-fp=xx
> >
> > mips-*-gcc -march=mips1 fp.c ==> generates fp32 code mips-*-gcc
> > -march=mips2 fp.c ==> generates fpxx code mips-*-gcc -march=mips32r2
> > fp.c ==> generates fpxx code mips-*-gcc -march=mips32r2 -mfp64 fp.c
> > ==> generates fp64 code mips-*-gcc -march=mips_n fp.c ==> generates
> > fp64 code
> >
> > --with-o32-fp=64
> >
> > mips-*-gcc -march=mips1 fp.c ==> generates fp32 code mips-*-gcc
> > -march=mips2 fp.c ==> generates fpxx code mips-*-gcc -march=mips32r2
> > fp.c ==> generates fp64 code mips-*-gcc -march=mips32r2 -mfp64 fp.c
> > ==> generates fp64 code mips-*-gcc -march=mips32r2 -mfpxx fp.c ==>
> > generates fpxx code mips-*-gcc -march=mips_n fp.c ==> generates fp64
> > code
> >
> > With these defaults, the closest supported ABI is used for each
> > architecture based on the --with-o32-fp build option. The only one I
> > really care about is the middle one as it makes full use of th
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford writes: > Matthew Fortune 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
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune 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
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> >> I think instead we should have a configuration switch that allows a
>> >> particular -mfp option to be inserted alongside -mabi=32 if no
>> >> explicit -mfp is given. This is how most --with options work. Maybe
>> >> --with-fp- 32={32|64|xx}? Specific triples could set a default value
>> if they like.
>> >> E.g. the MTI, SDE and mipsisa* ones would probably want to default to
>> >> -- with-32-fp=xx. Triples aimed at MIPS IV and below would stay as
>> >> they are. (MIPS IV is sometimes used with -mabi=32.)
>> >>
>> >> --with-fp-32 isn't the greatest name but is at least consistent with
>> >> --with-arch-32 and -mabi=32. Maybe --with-fp-32=64 is so weird that
>> >> breaking consistency is better though.
>> >
>> > Tying the use of fpxx by default to a configure time setting is OK
>> > with me. When enabled it would still have to follow the rules as
>> > defined in the design in that it can only apply to architectures that
>> > can support the variant.
>>
>> Right. It's really equivalent to putting the -mfp on every command line
>> that doesn't have one.
>>
>> > Currently that means everything but mips1.
>>
>> Yeah, using -mips1 on a --with-{o}32-fp=xx toolchain would be an error.
>>
>> > I'm not sure this is the same as tying an ABI to an architecture as
>> > both fp32 and fpxx are O32 and link compatible. Perhaps the configure
>> > switch would be --with-o32-fp={32|64|xx}. This shows it is just an O32
>> > related setting.
>>
>> What I meant is that -march= and -mips shouldn't imply a different -mfp
>> setting. The -mfp setting should be self-contained and it should be an
>> error if the architecture isn't compatible.
>>
>> We might be in violent agreement here :-) Like I say, I was just a bit
>> worried by the earlier -mips32r2 thing because there was a time when a -
>> mips option really could imply things like -mabi, -mgp and -mfp.
>>
>> --with-o32-fp would be OK with me. I'm just worried about the ABI being
>> spelt differently from -mabi=, but there's probably no perfect
>> alternative.
>
> I'd like to encourage the perspective that -mfp* options do not lead to
> a different ABI in the same sense that other variations do. While it is
> true that the calling conventions and code generation rules vary, 2 out
> of 3 combinations of -mfp32 -mfpxx and -mfp64 with -mabi=o32 are link
> compatible.
-mfp32 and -mfp64 aren't link-compatible though, so -mfp is part of the ABI.
What you're adding is a new variant that is individually link-compatible
with the other two (but obviously not both simultaneously). It's a third
ABI variant in itself.
> The introduction of the modeless O32 ABI is intended to
> remove the part of the O32 definition that says 'FR=0' and hence the
> architecture then gets to dictate this and the generated code is still
> O32. It is true today that we have several architectures that mandate
> FR=0, some that cannot support fpxx and some that can support all fp*
> variations. I see nothing preventing the future having an architecture
> only supporting FR=1 though which we should also think about.
Agreed.
> When considering such a scenario it would be highly desirable for the
> following to just work as I believe architectural restrictions should
> be accounted for when designing default options. If the architecture
> gives no choice then it should just work IMO:
>
> Some ideas (speculating that someone builds a core called mips_n with
> only FR=1):
>
> --with-o32-fp=32
>
> mips-*-gcc -march=mips1 fp.c ==> generates fp32 code
> mips-*-gcc -march=mips2 fp.c ==> generates fp32 code
> mips-*-gcc -march=mips32r2 fp.c ==> generates fp32 code
> mips-*-gcc -march=mips32r2 -mfp64 fp.c ==> generates fp64 code
> mips-*-gcc -march=mips_n fp.c ==> generates fp64 code
>
> --with-o32-fp=xx
>
> mips-*-gcc -march=mips1 fp.c ==> generates fp32 code
> mips-*-gcc -march=mips2 fp.c ==> generates fpxx code
> mips-*-gcc -march=mips32r2 fp.c ==> generates fpxx code
> mips-*-gcc -march=mips32r2 -mfp64 fp.c ==> generates fp64 code
> mips-*-gcc -march=mips_n fp.c ==> generates fp64 code
>
> --with-o32-fp=64
>
> mips-*-gcc -march=mips1 fp.c ==> generates fp32 code
> mips-*-gcc -march=mips2 fp.c ==> generates fpxx code
> mips-*-gcc -march=mips32r2 fp.c ==> generates fp64 code
> mips-*-gcc -march=mips32r2 -mfp64 fp.c ==> generates fp64 code
> mips-*-gcc -march=mips32r2 -mfpxx fp.c ==> generates fpxx code
> mips-*-gcc -march=mips_n fp.c ==> generates fp64 code
>
> With these defaults, the closest supported ABI is used for each
> architecture based on the --with-o32-fp build option. The only one I
> really care about is the middle one as it makes full use of the O32 FPXX
> ABI without a user needing to account for arch restrictions.
Note that --with-* options just insert a canned -mfoo=bar option under
certain conditions, with those conditions being the same regardless of "bar".
So --with-o32-fp=32 should inser
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Hi Richard/all,
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.
Sections 9 and 10 contain pretty much all the changes and a fresh read is
better than me attempting to summarise. All the attributes, flags, etc are now
defined with specific values and specific comments regarding kernel support for
UFR have been added.
I have an implementation of everything except the program loader which I will
post to ensure the overall approach in code is acceptable. I'll do this on each
project's list appropriately. Since I am only just starting testing I have no
test cases to offer alongside the patches currently, I will be working on that
next. I'm deferring writing all the tests in case the implementation/behaviour
changes, hence initial review for now.
The implementation in GCC relies on LRA due to the way in which caller-save is
handled. A patch to enable LRA and fix all regressions is being developed
concurrently and will be posted ready for stage 1.
Let me know if there is any feedback on the updated spec.
I'm afraid the last aspect we discussed is still a point of contention :-) I'm
sure we'll get there though. I've added more comments inline below:
Richard Sandiford writes:
> Matthew Fortune writes:
> >> I think instead we should have a configuration switch that allows a
> >> particular -mfp option to be inserted alongside -mabi=32 if no
> >> explicit -mfp is given. This is how most --with options work. Maybe
> >> --with-fp- 32={32|64|xx}? Specific triples could set a default value
> if they like.
> >> E.g. the MTI, SDE and mipsisa* ones would probably want to default to
> >> -- with-32-fp=xx. Triples aimed at MIPS IV and below would stay as
> >> they are. (MIPS IV is sometimes used with -mabi=32.)
> >>
> >> --with-fp-32 isn't the greatest name but is at least consistent with
> >> --with-arch-32 and -mabi=32. Maybe --with-fp-32=64 is so weird that
> >> breaking consistency is better though.
> >
> > Tying the use of fpxx by default to a configure time setting is OK
> > with me. When enabled it would still have to follow the rules as
> > defined in the design in that it can only apply to architectures that
> > can support the variant.
>
> Right. It's really equivalent to putting the -mfp on every command line
> that doesn't have one.
>
> > Currently that means everything but mips1.
>
> Yeah, using -mips1 on a --with-{o}32-fp=xx toolchain would be an error.
>
> > I'm not sure this is the same as tying an ABI to an architecture as
> > both fp32 and fpxx are O32 and link compatible. Perhaps the configure
> > switch would be --with-o32-fp={32|64|xx}. This shows it is just an O32
> > related setting.
>
> What I meant is that -march= and -mips shouldn't imply a different -mfp
> setting. The -mfp setting should be self-contained and it should be an
> error if the architecture isn't compatible.
>
> We might be in violent agreement here :-) Like I say, I was just a bit
> worried by the earlier -mips32r2 thing because there was a time when a -
> mips option really could imply things like -mabi, -mgp and -mfp.
>
> --with-o32-fp would be OK with me. I'm just worried about the ABI being
> spelt differently from -mabi=, but there's probably no perfect
> alternative.
I'd like to encourage the perspective that -mfp* options do not lead to a
different ABI in the same sense that other variations do. While it is true that
the calling conventions and code generation rules vary, 2 out of 3 combinations
of -mfp32 -mfpxx and -mfp64 with -mabi=o32 are link compatible. The
introduction of the modeless O32 ABI is intended to remove the part of the O32
definition that says 'FR=0' and hence the architecture then gets to dictate
this and the generated code is still O32. It is true today that we have several
architectures that mandate FR=0, some that cannot support fpxx and some that
can support all fp* variations. I see nothing preventing the future having an
architecture only supporting FR=1 though which we should also think about. When
considering such a scenario it would be highly desirable for the following to
just work as I believe architectural restrictions should be accounted for when
designing default options. If the architecture gives no choice then it should
just work IMO:
Some ideas (speculating that someone builds a core called mips_n with only
FR=1):
--with-o32-fp=32
mips-*-gcc -march=mips1 fp.c ==> generates fp32 code
mips-*-gcc -march=mips2 fp.c ==> generates fp32 code
mips-*-gcc -march=mips32r2 fp.c ==> generates fp32 code
mips-*-gcc -march=mips32r2 -mfp64 fp.c ==> generates fp64 code
mips-*-gcc -march=mips_n fp.c ==> generates fp64 code
--with-o32-fp=xx
mips-*-gcc -march=mips1 fp.c ==> generates fp32 code
mips-*-gcc -march=mips2 fp.c ==> gene
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes:
>> I think instead we should have a configuration switch that allows a
>> particular -mfp option to be inserted alongside -mabi=32 if no explicit
>> -mfp is given. This is how most --with options work. Maybe --with-fp-
>> 32={32|64|xx}? Specific triples could set a default value if they like.
>> E.g. the MTI, SDE and mipsisa* ones would probably want to default to --
>> with-32-fp=xx. Triples aimed at MIPS IV and below would stay as they
>> are. (MIPS IV is sometimes used with -mabi=32.)
>>
>> --with-fp-32 isn't the greatest name but is at least consistent with
>> --with-arch-32 and -mabi=32. Maybe --with-fp-32=64 is so weird that
>> breaking consistency is better though.
>
> Tying the use of fpxx by default to a configure time setting is OK with
> me. When enabled it would still have to follow the rules as defined in
> the design in that it can only apply to architectures that can support
> the variant.
Right. It's really equivalent to putting the -mfp on every command line
that doesn't have one.
> Currently that means everything but mips1.
Yeah, using -mips1 on a --with-{o}32-fp=xx toolchain would be an error.
> I'm not sure this is the same as tying an ABI to an architecture as
> both fp32 and fpxx are O32 and link compatible. Perhaps the configure
> switch would be --with-o32-fp={32|64|xx}. This shows it is just an O32
> related setting.
What I meant is that -march= and -mips shouldn't imply a different
-mfp setting. The -mfp setting should be self-contained and it should
be an error if the architecture isn't compatible.
We might be in violent agreement here :-) Like I say, I was just a
bit worried by the earlier -mips32r2 thing because there was a time
when a -mips option really could imply things like -mabi, -mgp and -mfp.
--with-o32-fp would be OK with me. I'm just worried about the ABI
being spelt differently from -mabi=, but there's probably no perfect
alternative.
>> > Currently newlib's implementation is assembly code with no
>> > .gnu_attributes. Under the rules above this would start to be
>> > implicitly tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we
>> > transition this to fpxx and still have the modules buildable with old
>> > tools as well? I'm not sure if it will be acceptable to say that it
>> > has to be rewritten in C.
>>
>> If it's assembled as -mfpxx then it'll be implicitly tagged with the new
>> .gnu_attribute rather than 4,1. If it's not assembled as -mfpxx then
>> 4,1 would be the right choice.
>
> So this would be dependent on the build system ensuring -mfpxx is passed
> as appropriate if the toolchain supports it. There is some risk in this
> too if the existing code (which I know is not fpxx safe) gets built with
> a new toolchain then it will be tagged as fpxx. I wonder if this tells
> us that command line options cannot safely set the FP ABI away from the
> default. Instead only the .module and .gnu_attribute can set it as only
> the source code can know what FP mode it was written for. The change to
> your 4 points above would be that the module level setting is not
> impacted by the command line -mfp options.
I don't think that's necessary. For one thing, there's always the
problem with unannotated asm code that the command-line options might
be wrong. There's often not much we can do about that. E.g. we have to
assume that code assembled as -mabi=n32 really is n32 code and not n64
code (and produce a 32-bit rather than 64-bit ELF). There's no way of
hedging our bets in that case: we have to pick an ABI.
For another, leaving the attribute as the default 0 makes the object
compatible with everything, so a file assembled with the wrong -mfpyy
could still be linked with other -mfpyy files. I don't think it gives
us anything extra.
The interaction between .module and command-line options should be the
same for all .module/.set options.
Thanks,
Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford writes:
> Matthew Fortune writes:
> > Richard Sandiford writes:
> >> Matthew Fortune writes:
> >> > Are you're OK with automatically selecting fpxx if no -mfp option,
> >> > no .module and no .gnu_attribute exists? Such code would currently
> >> > end up as FP ABI Any even if FP code was present, I don't suppose
> >> > anything would get worse if this existing behaviour simply
> continued though.
> >>
> >> The -mfp setting is usually implied by the -mabi setting. I don't
> >> think we should change that. Since this is a new mode, and since the
> >> fpxx markup will be available from the start, everyone using fpxx
> >> should say so explicitly.
> >>
> >> E.g. maybe the rules should be:
> >>
> >> (1) Any explicit .gnu_attribute 4 is always used, although we might
> >> give a diagnostic if it's incompatible with the module-level
> >> setting.
> >>
> >> (2) Otherwise, if the code does not use FP then the attribute is left
> >> at the default of 0.
> >>
> >> (3) Otherwise, a nonzero .gnu_attribute 4 is implied from the module-
> >> level
> >> setting.
> >>
> >> (4) For compatibility, -mabi=32 continues to imply -mfp32. fpxx mode
> >> must
> >> be selected explicitly.
> >>
> >> Which was supposed to be simple, but maybe isn't so much.
> >
> > This sounds OK. I'd rather (4) permitted transition to fpxx for 'safe'
> > FP code but let's see if we can do without it. Setjmp/longjmp are the
> > only obvious candidates for using FP code in assembly files and these
> > need to transition to fpxx.
> >
> > The glibc implementation of setjmp/longjmp is in C so the new defaults
> > from the compiler will lead to this being fpxx as -mips32r2 will imply
> > -mfpxx so that is OK, these modules will be tagged as fpxx.
>
> Hmm, I don't think -mips32r2 should make any difference here.
> You've specified it so that fpxx will work with MIPS II and above and
> I'd prefer not to have an architecture option implicitly changing the
> ABI. (They sometimes did in the long-distant past but it just led to
> confusion.)
I didn't mean to single out mips32r2 here it applies equally to anything except
mips1 with O32.
> I think instead we should have a configuration switch that allows a
> particular -mfp option to be inserted alongside -mabi=32 if no explicit
> -mfp is given. This is how most --with options work. Maybe --with-fp-
> 32={32|64|xx}? Specific triples could set a default value if they like.
> E.g. the MTI, SDE and mipsisa* ones would probably want to default to --
> with-32-fp=xx. Triples aimed at MIPS IV and below would stay as they
> are. (MIPS IV is sometimes used with -mabi=32.)
>
> --with-fp-32 isn't the greatest name but is at least consistent with
> --with-arch-32 and -mabi=32. Maybe --with-fp-32=64 is so weird that
> breaking consistency is better though.
Tying the use of fpxx by default to a configure time setting is OK with me.
When enabled it would still have to follow the rules as defined in the design
in that it can only apply to architectures that can support the variant.
Currently that means everything but mips1. I'm not sure this is the same as
tying an ABI to an architecture as both fp32 and fpxx are O32 and link
compatible. Perhaps the configure switch would be --with-o32-fp={32|64|xx}.
This shows it is just an O32 related setting.
> > Currently newlib's implementation is assembly code with no
> > .gnu_attributes. Under the rules above this would start to be
> > implicitly tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we
> > transition this to fpxx and still have the modules buildable with old
> > tools as well? I'm not sure if it will be acceptable to say that it
> > has to be rewritten in C.
>
> If it's assembled as -mfpxx then it'll be implicitly tagged with the new
> .gnu_attribute rather than 4,1. If it's not assembled as -mfpxx then
> 4,1 would be the right choice.
So this would be dependent on the build system ensuring -mfpxx is passed as
appropriate if the toolchain supports it. There is some risk in this too if the
existing code (which I know is not fpxx safe) gets built with a new toolchain
then it will be tagged as fpxx. I wonder if this tells us that command line
options cannot safely set the FP ABI away from the default. Instead only the
.module and .gnu_attribute can set it as only the source code can know what FP
mode it was written for. The change to your 4 points above would be that the
module level setting is not impacted by the command line -mfp options.
This would then require us to have an explicit attribute in the source to
select fpxx which would need to be optionally included dependent on assembler
support for .module. (The relaxation would have helped here of course.)
> Thanks,
> Richard
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > Are you're OK with automatically selecting fpxx if no -mfp option, no
>> > .module and no .gnu_attribute exists? Such code would currently end up
>> > as FP ABI Any even if FP code was present, I don't suppose anything
>> > would get worse if this existing behaviour simply continued though.
>>
>> The -mfp setting is usually implied by the -mabi setting. I don't think
>> we should change that. Since this is a new mode, and since the fpxx
>> markup will be available from the start, everyone using fpxx should say
>> so explicitly.
>>
>> E.g. maybe the rules should be:
>>
>> (1) Any explicit .gnu_attribute 4 is always used, although we might
>> give a diagnostic if it's incompatible with the module-level
>> setting.
>>
>> (2) Otherwise, if the code does not use FP then the attribute is left
>> at the default of 0.
>>
>> (3) Otherwise, a nonzero .gnu_attribute 4 is implied from the module-
>> level
>> setting.
>>
>> (4) For compatibility, -mabi=32 continues to imply -mfp32. fpxx mode
>> must
>> be selected explicitly.
>>
>> Which was supposed to be simple, but maybe isn't so much.
>
> This sounds OK. I'd rather (4) permitted transition to fpxx for 'safe'
> FP code but let's see if we can do without it. Setjmp/longjmp are the
> only obvious candidates for using FP code in assembly files and these
> need to transition to fpxx.
>
> The glibc implementation of setjmp/longjmp is in C so the new defaults
> from the compiler will lead to this being fpxx as -mips32r2 will imply
> -mfpxx so that is OK, these modules will be tagged as fpxx.
Hmm, I don't think -mips32r2 should make any difference here.
You've specified it so that fpxx will work with MIPS II and above
and I'd prefer not to have an architecture option implicitly changing
the ABI. (They sometimes did in the long-distant past but it just
led to confusion.)
I think instead we should have a configuration switch that allows
a particular -mfp option to be inserted alongside -mabi=32 if no explicit
-mfp is given. This is how most --with options work. Maybe
--with-fp-32={32|64|xx}? Specific triples could set a default value if
they like. E.g. the MTI, SDE and mipsisa* ones would probably want to
default to --with-32-fp=xx. Triples aimed at MIPS IV and below would
stay as they are. (MIPS IV is sometimes used with -mabi=32.)
--with-fp-32 isn't the greatest name but is at least consistent with
--with-arch-32 and -mabi=32. Maybe --with-fp-32=64 is so weird
that breaking consistency is better though.
> Currently newlib's implementation is assembly code with no
> .gnu_attributes. Under the rules above this would start to be implicitly
> tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we transition
> this to fpxx and still have the modules buildable with old tools as
> well? I'm not sure if it will be acceptable to say that it has to be
> rewritten in C.
If it's assembled as -mfpxx then it'll be implicitly tagged with the
new .gnu_attribute rather than 4,1. If it's not assembled as -mfpxx
then 4,1 would be the right choice.
Thanks,
Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford writes: > Matthew Fortune writes: > > Are you're OK with automatically selecting fpxx if no -mfp option, no > > .module and no .gnu_attribute exists? Such code would currently end up > > as FP ABI Any even if FP code was present, I don't suppose anything > > would get worse if this existing behaviour simply continued though. > > The -mfp setting is usually implied by the -mabi setting. I don't think > we should change that. Since this is a new mode, and since the fpxx > markup will be available from the start, everyone using fpxx should say > so explicitly. > > E.g. maybe the rules should be: > > (1) Any explicit .gnu_attribute 4 is always used, although we might > give a diagnostic if it's incompatible with the module-level > setting. > > (2) Otherwise, if the code does not use FP then the attribute is left > at the default of 0. > > (3) Otherwise, a nonzero .gnu_attribute 4 is implied from the module- > level > setting. > > (4) For compatibility, -mabi=32 continues to imply -mfp32. fpxx mode > must > be selected explicitly. > > Which was supposed to be simple, but maybe isn't so much. This sounds OK. I'd rather (4) permitted transition to fpxx for 'safe' FP code but let's see if we can do without it. Setjmp/longjmp are the only obvious candidates for using FP code in assembly files and these need to transition to fpxx. The glibc implementation of setjmp/longjmp is in C so the new defaults from the compiler will lead to this being fpxx as -mips32r2 will imply -mfpxx so that is OK, these modules will be tagged as fpxx. Currently newlib's implementation is assembly code with no .gnu_attributes. Under the rules above this would start to be implicitly tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we transition this to fpxx and still have the modules buildable with old tools as well? I'm not sure if it will be acceptable to say that it has to be rewritten in C. There will also be uclibc and bionic to deal with too for setjmp/longjmp but I don't have their source to hand. Regards, Matthew
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes: > Are you're OK with automatically selecting fpxx if no -mfp option, no > .module and no .gnu_attribute exists? Such code would currently end up > as FP ABI Any even if FP code was present, I don't suppose anything > would get worse if this existing behaviour simply continued though. The -mfp setting is usually implied by the -mabi setting. I don't think we should change that. Since this is a new mode, and since the fpxx markup will be available from the start, everyone using fpxx should say so explicitly. E.g. maybe the rules should be: (1) Any explicit .gnu_attribute 4 is always used, although we might give a diagnostic if it's incompatible with the module-level setting. (2) Otherwise, if the code does not use FP then the attribute is left at the default of 0. (3) Otherwise, a nonzero .gnu_attribute 4 is implied from the module-level setting. (4) For compatibility, -mabi=32 continues to imply -mfp32. fpxx mode must be selected explicitly. Which was supposed to be simple, but maybe isn't so much. Thanks, Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford writes: > Matthew Fortune writes: > >> Matthew Fortune writes: > >> >> > Sorry, forgot about that. In that case maybe program headers > >> >> > would be best, like you say. I.e. we could use a combination of > >> >> > GNU attributes and a new program header, with the program header > >> >> > hopefully being more general than for just this case. I suppose > >> >> > this comes back to the thread from binutils@ last year about how > >> >> > to manage the dwindling number of free flags: > >> >> > > >> >> > https://www.sourceware.org/ml/binutils/2013-09/msg00039.html > >> >> > to https://www.sourceware.org/ml/binutils/2013-09/msg00099.html > >> >> > > >> > > >> > There are a couple of issues to resolve in order to use gnu > >> > attributes to record FP requirements at the module level. As it > >> > currently stands gnu attributes are controlled via the > >> > .gnu_attribute directive and these are emitted explicitly by the > >> > compiler. I think it is important that a more meaningful directive > >> > is available but it will need to interact nicely with the > .gnu_attribute as well. > >> > > >> > The first problem is that there will be new ways to influence > >> > whether a gnu attribute is emitted or not. i.e. the command line > >> > options -mfp32, -mfpxx, -mfp64 will infer the relevant attribute > >> > Tag_GNU_MIPS_ABI_FP and if the .module directive is present then > >> > that would override it. Will there be any problems with a new ways > >> > to > >> generate a gnu attribute? > >> > >> I think we should just give an error if any .gnu_attributes are > >> inconsistent with the module-level setting (whether that comes from > >> .module or command-line flags). > > > > I would need to account for the -msoft-float and -msingle-float > > command line options to calculate module-level setting in order to do > > this, which is fine. There is however no way to infer the no-float ABI > > from command line options as it is not passed through from the GCC > > driver. This would mean the no-float ABI would always conflict with > > the module level setting. > > -mno-float the GCC option doesn't really select a different ABI. > It does leave the FP attribute as being the default 0/dont-care, but > that's just like it would be when compiling most hand-written assembly > code, including code written before -mno-float or .gnu_attribute was > invented. > > > I suspect the only answer is to make an exception and allow a > > .gnu_attribute 4,0 to take precedence over a command line option (but > > not a .module option). This seems a little convoluted in the end. > > I don't think we should ever override an explicit .gnu_attribute. > The most we can do is report a contradiction. > > >> > The second problem is that in order to support relaxing a mode > >> > requirement then any up-front directive/command line option that > >> > sets a specific fp32/fp64 requirement needs to be updated to fpxx. > >> > With gnu attributes this would mean updating an existing > >> > Tag_GNU_MIPS_ABI_FP setting to be modeless. > >> > >> Not sure what you mean here, sorry. > > > > At the end of a unit we will know whether an FP32 or FP64 ABI can be > > relaxed to FPXX. This will happen if no floating point code has been > > emitted that uses odd numbered registers. All I was checking is that > > it is going to be acceptable to alter the FP ABI attribute even if it > > was set using the .gnu_attribute directive. I know I 'can' do it in > > the code as I have it working already just checking that it is OK. I > > suppose this case is going to be quite rare (hand written assembly > > code that includes a .gnu_attribute 4,1 which is mode safe) but I'd > > like to catch as many cases as possible and relax the ABI. > > Yeah, I don't think we should do any relaxation like that. If a > specific attribute value is chosen we should honour it even if it > doesn't seem necessary. If -mfp32, -mfp64, .module fp=32 or .module > fp=64 is used we should honour it even if -mfpxx or .module fp=xx seems > OK. Are you're OK with automatically selecting fpxx if no -mfp option, no .module and no .gnu_attribute exists? Such code would currently end up as FP ABI Any even if FP code was present, I don't suppose anything would get worse if this existing behaviour simply continued though. For this to be sufficient we would be making the assumption that there is almost no hand written code that has a .gnu_attribute directive nor build system that explicitly uses the -mfp32 option. I think this will certainly hold true for assembly modules that have no FP code in them but presumably anyone who has hand-written FP code will have used the .gnu_attribute. We will lose the ability for such modules to quietly transition to fpxx but I have no data to say how many of such modules exist or may exist in the future. I still need to check if there are any hand written FP modules in the standard libraries. I am concerned about this aspect but
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes: >> Matthew Fortune writes: >> >> > Sorry, forgot about that. In that case maybe program headers would >> >> > be best, like you say. I.e. we could use a combination of GNU >> >> > attributes and a new program header, with the program header >> >> > hopefully being more general than for just this case. I suppose >> >> > this comes back to the thread from binutils@ last year about how to >> >> > manage the dwindling number of free flags: >> >> > >> >> > https://www.sourceware.org/ml/binutils/2013-09/msg00039.html >> >> > to https://www.sourceware.org/ml/binutils/2013-09/msg00099.html >> >> > >> > >> > There are a couple of issues to resolve in order to use gnu attributes >> > to record FP requirements at the module level. As it currently stands >> > gnu attributes are controlled via the .gnu_attribute directive and >> > these are emitted explicitly by the compiler. I think it is important >> > that a more meaningful directive is available but it will need to >> > interact nicely with the .gnu_attribute as well. >> > >> > The first problem is that there will be new ways to influence whether >> > a gnu attribute is emitted or not. i.e. the command line options >> > -mfp32, -mfpxx, -mfp64 will infer the relevant attribute >> > Tag_GNU_MIPS_ABI_FP and if the .module directive is present then that >> > would override it. Will there be any problems with a new ways to >> generate a gnu attribute? >> >> I think we should just give an error if any .gnu_attributes are >> inconsistent with the module-level setting (whether that comes from >> .module or command-line flags). > > I would need to account for the -msoft-float and -msingle-float command > line options to calculate module-level setting in order to do this, > which is fine. There is however no way to infer the no-float ABI from > command line options as it is not passed through from the GCC > driver. This would mean the no-float ABI would always conflict with the > module level setting. -mno-float the GCC option doesn't really select a different ABI. It does leave the FP attribute as being the default 0/dont-care, but that's just like it would be when compiling most hand-written assembly code, including code written before -mno-float or .gnu_attribute was invented. > I suspect the only answer is to make an exception > and allow a .gnu_attribute 4,0 to take precedence over a command line > option (but not a .module option). This seems a little convoluted in the > end. I don't think we should ever override an explicit .gnu_attribute. The most we can do is report a contradiction. >> > The second problem is that in order to support relaxing a mode >> > requirement then any up-front directive/command line option that sets >> > a specific fp32/fp64 requirement needs to be updated to fpxx. With gnu >> > attributes this would mean updating an existing Tag_GNU_MIPS_ABI_FP >> > setting to be modeless. >> >> Not sure what you mean here, sorry. > > At the end of a unit we will know whether an FP32 or FP64 ABI can be > relaxed to FPXX. This will happen if no floating point code has been > emitted that uses odd numbered registers. All I was checking is that it > is going to be acceptable to alter the FP ABI attribute even if it was > set using the .gnu_attribute directive. I know I 'can' do it in the code > as I have it working already just checking that it is OK. I suppose this > case is going to be quite rare (hand written assembly code that includes > a .gnu_attribute 4,1 which is mode safe) but I'd like to catch as many > cases as possible and relax the ABI. Yeah, I don't think we should do any relaxation like that. If a specific attribute value is chosen we should honour it even if it doesn't seem necessary. If -mfp32, -mfp64, .module fp=32 or .module fp=64 is used we should honour it even if -mfpxx or .module fp=xx seems OK. Thanks, Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
> Matthew Fortune writes: > >> > Sorry, forgot about that. In that case maybe program headers would > >> > be best, like you say. I.e. we could use a combination of GNU > >> > attributes and a new program header, with the program header > >> > hopefully being more general than for just this case. I suppose > >> > this comes back to the thread from binutils@ last year about how to > >> > manage the dwindling number of free flags: > >> > > >> > https://www.sourceware.org/ml/binutils/2013-09/msg00039.html > >> > to https://www.sourceware.org/ml/binutils/2013-09/msg00099.html > >> > > > > > There are a couple of issues to resolve in order to use gnu attributes > > to record FP requirements at the module level. As it currently stands > > gnu attributes are controlled via the .gnu_attribute directive and > > these are emitted explicitly by the compiler. I think it is important > > that a more meaningful directive is available but it will need to > > interact nicely with the .gnu_attribute as well. > > > > The first problem is that there will be new ways to influence whether > > a gnu attribute is emitted or not. i.e. the command line options > > -mfp32, -mfpxx, -mfp64 will infer the relevant attribute > > Tag_GNU_MIPS_ABI_FP and if the .module directive is present then that > > would override it. Will there be any problems with a new ways to > generate a gnu attribute? > > I think we should just give an error if any .gnu_attributes are > inconsistent with the module-level setting (whether that comes from > .module or command-line flags). I would need to account for the -msoft-float and -msingle-float command line options to calculate module-level setting in order to do this, which is fine. There is however no way to infer the no-float ABI from command line options as it is not passed through from the GCC driver. This would mean the no-float ABI would always conflict with the module level setting. I suspect the only answer is to make an exception and allow a .gnu_attribute 4,0 to take precedence over a command line option (but not a .module option). This seems a little convoluted in the end. The only other alternative is to just allow the .module fp=... options to act as human readable aliases for the .gnu_attribute options and take whatever comes last. > > The second problem is that in order to support relaxing a mode > > requirement then any up-front directive/command line option that sets > > a specific fp32/fp64 requirement needs to be updated to fpxx. With gnu > > attributes this would mean updating an existing Tag_GNU_MIPS_ABI_FP > > setting to be modeless. > > Not sure what you mean here, sorry. At the end of a unit we will know whether an FP32 or FP64 ABI can be relaxed to FPXX. This will happen if no floating point code has been emitted that uses odd numbered registers. All I was checking is that it is going to be acceptable to alter the FP ABI attribute even if it was set using the .gnu_attribute directive. I know I 'can' do it in the code as I have it working already just checking that it is OK. I suppose this case is going to be quite rare (hand written assembly code that includes a .gnu_attribute 4,1 which is mode safe) but I'd like to catch as many cases as possible and relax the ABI. Regards, Matthew
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes: >> > Sorry, forgot about that. In that case maybe program headers would be >> > best, like you say. I.e. we could use a combination of GNU attributes >> > and a new program header, with the program header hopefully being more >> > general than for just this case. I suppose this comes back to the >> > thread from binutils@ last year about how to manage the dwindling >> > number of free flags: >> > >> > https://www.sourceware.org/ml/binutils/2013-09/msg00039.html >> > to https://www.sourceware.org/ml/binutils/2013-09/msg00099.html >> > > > There are a couple of issues to resolve in order to use gnu attributes > to record FP requirements at the module level. As it currently stands > gnu attributes are controlled via the .gnu_attribute directive and these > are emitted explicitly by the compiler. I think it is important that a > more meaningful directive is available but it will need to interact > nicely with the .gnu_attribute as well. > > The first problem is that there will be new ways to influence whether a > gnu attribute is emitted or not. i.e. the command line options -mfp32, > -mfpxx, -mfp64 will infer the relevant attribute Tag_GNU_MIPS_ABI_FP and > if the .module directive is present then that would override it. Will > there be any problems with a new ways to generate a gnu attribute? I think we should just give an error if any .gnu_attributes are inconsistent with the module-level setting (whether that comes from .module or command-line flags). > The second problem is that in order to support relaxing a mode > requirement then any up-front directive/command line option that sets a > specific fp32/fp64 requirement needs to be updated to fpxx. With gnu > attributes this would mean updating an existing Tag_GNU_MIPS_ABI_FP > setting to be modeless. Not sure what you mean here, sorry. Thanks, Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
> > Sorry, forgot about that. In that case maybe program headers would be > > best, like you say. I.e. we could use a combination of GNU attributes > > and a new program header, with the program header hopefully being more > > general than for just this case. I suppose this comes back to the > > thread from binutils@ last year about how to manage the dwindling > > number of free flags: > > > > https://www.sourceware.org/ml/binutils/2013-09/msg00039.html > > to https://www.sourceware.org/ml/binutils/2013-09/msg00099.html > > There are a couple of issues to resolve in order to use gnu attributes to record FP requirements at the module level. As it currently stands gnu attributes are controlled via the .gnu_attribute directive and these are emitted explicitly by the compiler. I think it is important that a more meaningful directive is available but it will need to interact nicely with the .gnu_attribute as well. The first problem is that there will be new ways to influence whether a gnu attribute is emitted or not. i.e. the command line options -mfp32, -mfpxx, -mfp64 will infer the relevant attribute Tag_GNU_MIPS_ABI_FP and if the .module directive is present then that would override it. Will there be any problems with a new ways to generate a gnu attribute? The second problem is that in order to support relaxing a mode requirement then any up-front directive/command line option that sets a specific fp32/fp64 requirement needs to be updated to fpxx. With gnu attributes this would mean updating an existing Tag_GNU_MIPS_ABI_FP setting to be modeless. I don't think any other port does this kind of thing in binutils but that doesn't mean we can't I guess. Regards, Matthew
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
> Matthew Fortune writes: > >> >> If we do end up using ELF flags then maybe adding two new > >> >> EF_MIPS_ABI enums would be better. It's more likely to be trapped > >> >> by old loaders and avoids eating up those precious remaining bits. > >> > > >> > Sound's reasonable but I'm still trying to determine how this > >> > information can be propagated from loader to dynamic loader. > >> > >> The dynamic loader has access to the ELF headers so I didn't think it > >> would need any help. > > > > As I understand it the dynamic loader only has specific access to the > > program headers of the executable not the ELF headers. There is no > > question that the dynamic loader has access to DSO ELF headers but we > > need the start point too. > > Sorry, forgot about that. In that case maybe program headers would be > best, like you say. I.e. we could use a combination of GNU attributes > and a new program header, with the program header hopefully being more > general than for just this case. I suppose this comes back to the > thread from binutils@ last year about how to manage the dwindling number > of free flags: > > https://www.sourceware.org/ml/binutils/2013-09/msg00039.html > to https://www.sourceware.org/ml/binutils/2013-09/msg00099.html > > >> >> You didn't say specifically how a static program's crt code would > >> >> know whether it was linked as modeless or in a specific FR mode. > >> >> Maybe the linker could define a special hidden symbol? > >> > > >> > Why do you say crt rather than dlopen? The mode requirement should > >> > only matter if you want to change it and dlopen should be able to > >> > access information in the same way that a dynamic linker would. It > >> > may seem redundant but perhaps we end up having to mark an > >> > executable with mode requirements in two ways. The primary one > >> > being the ELF flag and the secondary one being a processor specific > >> > program header. The ELF flags are easy to use/already used for the > >> > program loader and when scanning the needs of an object being > >> > loaded, but the program header is something that is easy to inspect > for an already-loaded object. > >> > Overall though, a new program header would be sufficient in all > >> > cases, with a few modifications here and there. > >> > >> Sorry, what I meant was: how would an executable built with -static > >> be handled? And I was assuming it would be up to the executable's > >> startup code to set the FR mode. That startup code (from glibc) > >> would normally be modeless itself but would need to know whether any > >> FR0 or FR1 objects were linked in. (FWIW ifuncs have a similar > >> problem: without the loader to help, the startup code has to resolve > >> the ifuncs itself. The static linker defines special symbols around > >> a block of IRELATIVE relocs and then the startup code applies those > >> relocs in a similar way to the dynamic linker. I was thinking a > >> linker-defined symbol could be used to record the FR mode too.) > >> > >> But perhaps you were thinking of getting the kernel to set the FR > >> mode instead? > > > > I was thinking the kernel would set an initial FR mode that was at > > least compatible with the ELF flags. Do you feel all this should be > > done in user space? We only get user mode FR control in MIPS r5 so > > this would make it more challenging to get into FR1 mode for MIPS32r2. > > I'd prefer not to be able to load an FR1 program than crash in the crt > > while trying to turn it on. There is however some expectation that the > > kernel would trap and emulate UFR on MIPS32r2 for the dynamic loader > case anyway. > > Right -- the kernel needs to let userspace change FR if the dynamic > loader case is going to work. And I think if it's handled by userspace > for dynamic executables then it should be handled by userspace for > static ones too. Especially since the mechanism used for static > executables would then be the same as for bare metal, meaning that we > only really have 2 cases rather than 3. Although the dynamic case does mean mode switching must be possible at user level I do think it is important for the OS and bare metal crt to prepare an environment that is suitable for the original program including setting an appropriate FR mode. I would use the existing support for linux and bare metal for getting the fr mode correct for O32 vs N[32|64] as a basis for this. This initial guarantee would be quite helpful especially in the static link for linux userland as it simply wouldn't need to worry. I can understand the desire to keep the number of mechanisms to set FR mode to a minimum but the fact that bare metal runs privileged and linux userland runs unprivileged says to me that they will naturally take different paths on some of this. There are other aspects such as whether the kernel informs user land that UFR is available or not, via HWCAPs and consideration over what point we would want to see a failure when mode requ
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes: > That sounds OK to me. > > I'm aiming to have an experimental implementation of the calling > convention changes as soon as possible although I am having difficulties > getting the frx calling convention working correctly. > > The problem is that frx needs to treat registers as 64bit sometimes and > 32bit at other times. > a) I need the aliasing that 32bit registers gives me (use of an > even-numbered double clobbers the corresponding odd-numbered > single. This is to prevent both the double and odd numbered single being > used simultaneously. > b) I need the 64bit register layout to ensure that 64bit values in > caller-saved registers are saved as 64-bit (rather than 2x32-bit) and > 32-bit registers are saved as 32-bit and never combined into a 64-bit > save. Caller-save.c flattens the caller-save problem down to look at > only hard registers not modes which is frustrating. > > It looks like caller-save.c would need a lot of work to achieve b) with > 32-bit hard registers but I equally don't know how I could achieve a) > for 64-bit registers. I suspect a) is marginally easier to solve in the > end but have to find a way to say that using reg x as 64-bit prevents > allocation of x+1 as 32-bit despite registers being 64-bit. The easy > option is to go for 64-bit registers and never use odd-numbered > registers for single-precision or double-precision but I don't really > want frx to be limited to that if at all possible. Any suggestions? Treating it as a limited from of FR0 mode seems best. I don't think there's any practical way of doing (a) without making HARD_REGNO_NREGS be 2 for a DFmode FPR, at which point any wrong assumptions about paired registers in caller-save.c would kick in. We'd only be making this change in the next release cycle, and we really should look to move to LRA for that cycle too. caller-save.c is specific to reload and so wouldn't be a problem. Of course, you might need to do stuff in LRA instead. Thanks, Richard
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes: >> >> If we do end up using ELF flags then maybe adding two new EF_MIPS_ABI >> >> enums would be better. It's more likely to be trapped by old loaders >> >> and avoids eating up those precious remaining bits. >> > >> > Sound's reasonable but I'm still trying to determine how this >> > information can be propagated from loader to dynamic loader. >> >> The dynamic loader has access to the ELF headers so I didn't think it >> would need any help. > > As I understand it the dynamic loader only has specific access to the > program headers of the executable not the ELF headers. There is no > question that the dynamic loader has access to DSO ELF headers but we > need the start point too. Sorry, forgot about that. In that case maybe program headers would be best, like you say. I.e. we could use a combination of GNU attributes and a new program header, with the program header hopefully being more general than for just this case. I suppose this comes back to the thread from binutils@ last year about how to manage the dwindling number of free flags: https://www.sourceware.org/ml/binutils/2013-09/msg00039.html to https://www.sourceware.org/ml/binutils/2013-09/msg00099.html >> >> You didn't say specifically how a static program's crt code would >> >> know whether it was linked as modeless or in a specific FR mode. >> >> Maybe the linker could define a special hidden symbol? >> > >> > Why do you say crt rather than dlopen? The mode requirement should >> > only matter if you want to change it and dlopen should be able to >> > access information in the same way that a dynamic linker would. It may >> > seem redundant but perhaps we end up having to mark an executable with >> > mode requirements in two ways. The primary one being the ELF flag and >> > the secondary one being a processor specific program header. The ELF >> > flags are easy to use/already used for the program loader and when >> > scanning the needs of an object being loaded, but the program header >> > is something that is easy to inspect for an already-loaded object. >> > Overall though, a new program header would be sufficient in all cases, >> > with a few modifications here and there. >> >> Sorry, what I meant was: how would an executable built with -static be >> handled? And I was assuming it would be up to the executable's startup >> code to set the FR mode. That startup code (from glibc) would normally >> be modeless itself but would need to know whether any FR0 or FR1 objects >> were linked in. (FWIW ifuncs have a similar >> problem: without the loader to help, the startup code has to resolve the >> ifuncs itself. The static linker defines special symbols around a block >> of IRELATIVE relocs and then the startup code applies those relocs in a >> similar way to the dynamic linker. I was thinking a linker-defined >> symbol could be used to record the FR mode too.) >> >> But perhaps you were thinking of getting the kernel to set the FR mode >> instead? > > I was thinking the kernel would set an initial FR mode that was at least > compatible with the ELF flags. Do you feel all this should be done in > user space? We only get user mode FR control in MIPS r5 so this would > make it more challenging to get into FR1 mode for MIPS32r2. I'd prefer > not to be able to load an FR1 program than crash in the crt while trying > to turn it on. There is however some expectation that the kernel would > trap and emulate UFR on MIPS32r2 for the dynamic loader case anyway. Right -- the kernel needs to let userspace change FR if the dynamic loader case is going to work. And I think if it's handled by userspace for dynamic executables then it should be handled by userspace for static ones too. Especially since the mechanism used for static executables would then be the same as for bare metal, meaning that we only really have 2 cases rather than 3. > Is it OK to continue these library related discussions here or should I > split the bare metal handling to newlib and linux libraries to glibc? > There is value in keeping things together but equally it is perhaps off > topic. Not sure TBH, but noone's complained so far :-) Thanks, Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford writes > Doug Gilmore writes: > > On 02/24/2014 10:42 AM, Richard Sandiford wrote: > >>... > >>> AIUI the old form never really worked reliably due to things like > >>> newlib's setjmp not preserving the odd-numbered registers, so it > >>> doesn't > seem worth keeping around. Also, the old form is identified by the > GNU attribute (4, 4) so it'd be easy for the linker to reject links > between the old and the new form. > >>> > >>> That is true. You will have noticed a number of changes over recent > >>> months to start fixing fp64 as currently defined but having found > >>> this new solution then such fixes are no longer important. The lack > >>> of support for gp32 fp64 in linux is further reason to permit > >>> redefining it. Would you be happy to retain the same builtin defines > >>> for FP64 if changing its behaviour (i.e. __mips_fpr=64)? > >> > >>I think that should be OK. I suppose a natural follow-on question is > >>what __mips_fpr should be for -mfpxx. Maybe just 0? > > I think we should think carefully about just making -mfp64 just > disappear. > > The support has existed for bare iron for quite a while, and we do > > internal testing of MSA using -mfp64. I'd rather avoid a flag day. > > It would be good to continue recognizing that object files with > > attribute (4, 4) > > (-mfp64) are not compatible with other objects. > > Right, that was the idea. (4, 4) would always mean the current form of > -mfp64 and the linker would reject links between (4, 4) and the new - > mfp64 form. > > The flag day was more on the GCC and GAS side. I don't see the point in > supporting both forms there at the same time, since it significantly > complicates the interface and since AIUI the old form was never really > suitable for production use. That sounds OK to me. I'm aiming to have an experimental implementation of the calling convention changes as soon as possible although I am having difficulties getting the frx calling convention working correctly. The problem is that frx needs to treat registers as 64bit sometimes and 32bit at other times. a) I need the aliasing that 32bit registers gives me (use of an even-numbered double clobbers the corresponding odd-numbered single. This is to prevent both the double and odd numbered single being used simultaneously. b) I need the 64bit register layout to ensure that 64bit values in caller-saved registers are saved as 64-bit (rather than 2x32-bit) and 32-bit registers are saved as 32-bit and never combined into a 64-bit save. Caller-save.c flattens the caller-save problem down to look at only hard registers not modes which is frustrating. It looks like caller-save.c would need a lot of work to achieve b) with 32-bit hard registers but I equally don't know how I could achieve a) for 64-bit registers. I suspect a) is marginally easier to solve in the end but have to find a way to say that using reg x as 64-bit prevents allocation of x+1 as 32-bit despite registers being 64-bit. The easy option is to go for 64-bit registers and never use odd-numbered registers for single-precision or double-precision but I don't really want frx to be limited to that if at all possible. Any suggestions? The special handling for callee-saved registers is not a problem (I think) as it is all backend code for that (assuming a or b is resolved). Regards, Matthew
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Doug Gilmore writes: > On 02/24/2014 10:42 AM, Richard Sandiford wrote: >>... >>> AIUI the old form never really worked reliably due to things like >>> newlib's setjmp not preserving the odd-numbered registers, so it doesn't seem worth keeping around. Also, the old form is identified by the GNU attribute (4, 4) so it'd be easy for the linker to reject links between the old and the new form. >>> >>> That is true. You will have noticed a number of changes over recent >>> months to start fixing fp64 as currently defined but having found this >>> new solution then such fixes are no longer important. The lack of >>> support for gp32 fp64 in linux is further reason to permit redefining >>> it. Would you be happy to retain the same builtin defines for FP64 if >>> changing its behaviour (i.e. __mips_fpr=64)? >> >>I think that should be OK. I suppose a natural follow-on question >>is what __mips_fpr should be for -mfpxx. Maybe just 0? > I think we should think carefully about just making -mfp64 just disappear. > The support has existed for bare iron for quite a while, and we do internal > testing of MSA using -mfp64. I'd rather avoid a flag day. It would be > good to continue recognizing that object files with attribute (4, 4) > (-mfp64) are not compatible with other objects. Right, that was the idea. (4, 4) would always mean the current form of -mfp64 and the linker would reject links between (4, 4) and the new -mfp64 form. The flag day was more on the GCC and GAS side. I don't see the point in supporting both forms there at the same time, since it significantly complicates the interface and since AIUI the old form was never really suitable for production use. Thanks, Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford writes > >> AIUI the old form never really worked reliably due to things like > >> newlib's setjmp not preserving the odd-numbered registers, so it > >> doesn't seem worth keeping around. Also, the old form is identified > >> by the GNU attribute (4, 4) so it'd be easy for the linker to reject > >> links between the old and the new form. > > > > That is true. You will have noticed a number of changes over recent > > months to start fixing fp64 as currently defined but having found this > > new solution then such fixes are no longer important. The lack of > > support for gp32 fp64 in linux is further reason to permit redefining > > it. Would you be happy to retain the same builtin defines for FP64 if > > changing its behaviour (i.e. __mips_fpr=64)? > > I think that should be OK. I suppose a natural follow-on question is > what __mips_fpr should be for -mfpxx. Maybe just 0? I'm doing just that in my experimental implementation of all this. > If we want to be extra cautious we could define a second set of macros > alongside the old ones. > > >> You allow the mode to be changed midexecution if a new FR0 or FR1 > >> object is loaded. Is it really worth supporting that though? > >> It has the same problem as the ifuncs: once you've dlopen()ed an > >> object, you fix the mode for the whole program, even after the > dlclose(). > >> Unless we know of specific cases where this is needed, maybe it would > >> be safer to fix the mode before execution based on DT_NEEDED > >> libraries and allow the mode of modeless programs to be overridden by > >> an environment variable. > > > > Scanning the entire set of DT_NEEDED libraries would achieve most of > > what full dynamic mode switching gives us, it is essentially the first > > stage of the dynamic mode switching described in the proposal anyway. > > However, I am concerned about excluding dlopen()ed objects from mode > > selection though (not so worried about excluding ifunc, that could > > just fix the mode before resolving the first one). One specific > > concern is for Android where I believe we have the situation where > > native applications are loaded as (a form of) shared library. This > > means a mode requirement can be introduced late on. In an Android > > environment it is unlikely to be acceptable to have to do something > > special to load an application that happens to have a specific mode > > requirement so dynamic selection is useful. This is more of a > > transitional problem than anything but making it a smooth process is > > quite important. I'm also not sure that there is much more effort > > required for a dynamic linker to take account of dlopen()ed objects in > > addition to DT_NEEDED, changes are needed in this code regardless. > > As far as GNU/Linux goes, if we do end up with a function in something > like a modeless libm that is implemented as an FR-aware ifunc, that > would force the choice to be made early anyway. So we have this very > specific case where everything in the initial process is modeless, no > ifuncs take advantage of the FR setting, and a dlopen()ed object was > compiled as fr0 rather than modeless. I agree it's possible but it > seems unlikely. A reasonable point. > I know nothing about the way Android loading works though. :-) Could you > describe it in more detail? Is it significantly different from glibc's > dynamic loader running a PIE? I am working from fragments of information on this aspect still so I need to get more clarification from Android developers. My current understanding is that native parts of applications are actually shared libraries and form part of, but not necessarily the entry to, an application. Since such a shared library can't be 'required' by anything it must be loaded explicitly. I'll get clarification but the potential need for dynamic mode switching in Android need not affect the decision that GNU/Linux takes. > >> If we do end up using ELF flags then maybe adding two new EF_MIPS_ABI > >> enums would be better. It's more likely to be trapped by old loaders > >> and avoids eating up those precious remaining bits. > > > > Sound's reasonable but I'm still trying to determine how this > > information can be propagated from loader to dynamic loader. > > The dynamic loader has access to the ELF headers so I didn't think it > would need any help. As I understand it the dynamic loader only has specific access to the program headers of the executable not the ELF headers. There is no question that the dynamic loader has access to DSO ELF headers but we need the start point too. > >> You didn't say specifically how a static program's crt code would > >> know whether it was linked as modeless or in a specific FR mode. > >> Maybe the linker could define a special hidden symbol? > > > > Why do you say crt rather than dlopen? The mode requirement should > > only matter if you want to change it and dlopen should be able to > > access information in the same way
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
On 02/24/2014 10:42 AM, Richard Sandiford wrote: >... >> AIUI the old form never really worked reliably due to things like >> newlib's setjmp not preserving the odd-numbered registers, so it doesn't >>> seem worth keeping around. Also, the old form is identified by the GNU >>> attribute (4, 4) so it'd be easy for the linker to reject links between >>> the old and the new form. >> >> That is true. You will have noticed a number of changes over recent >> months to start fixing fp64 as currently defined but having found this >> new solution then such fixes are no longer important. The lack of >> support for gp32 fp64 in linux is further reason to permit redefining >> it. Would you be happy to retain the same builtin defines for FP64 if >> changing its behaviour (i.e. __mips_fpr=64)? > >I think that should be OK. I suppose a natural follow-on question >is what __mips_fpr should be for -mfpxx. Maybe just 0? I think we should think carefully about just making -mfp64 just disappear. The support has existed for bare iron for quite a while, and we do internal testing of MSA using -mfp64. I'd rather avoid a flag day. It would be good to continue recognizing that object files with attribute (4, 4) (-mfp64) are not compatible with other objects. Note that adding EF_MIPS_FP64 is a recent change, which was made to enable Linux kernel support, and there probably is little code out there that is dependent on it. I am more comfortable in changing the interpretation of EF_MIPS_FP64 to simply mean that the process is to be set with FR=1 mode as apposed to FR=0. This will allow us to ease our way off of -mfp64 to -mfr1 mode for those environments where FR=1 is really needed. Doug >...
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes: > Richard Sandiford writes >> I understand the need to deprecate the current -mgp32 -mfp64 behaviour. >> I don't think we should deprecate -mfp64 itself though. Instead, why >> not keep -mfp32 as meaning FR0, -mfp64 meaning FR1 and add -mfpxx for >> modeless? So rather than deprecating the -mgp32 -mfp64 combination and >> adding -mfr, we'd just make -mgp32 -mfp64 generate the new FR1 form in >> which the odd-numbered registers are call-clobbered rather than the old >> form in which they were call-saved. > > Extreme caution is the only reason why the design avoided changing fp64 > behaviour (basically in case anyone had serious objection). If you would > be happy with a change of behaviour for -mgp32 -mfp64 then that is a > great start. Yeah, my first impression is that keeping the current interface would be much better than adding a new set of options. >> AIUI the old form never really worked reliably due to things like >> newlib's setjmp not preserving the odd-numbered registers, so it doesn't >> seem worth keeping around. Also, the old form is identified by the GNU >> attribute (4, 4) so it'd be easy for the linker to reject links between >> the old and the new form. > > That is true. You will have noticed a number of changes over recent > months to start fixing fp64 as currently defined but having found this > new solution then such fixes are no longer important. The lack of > support for gp32 fp64 in linux is further reason to permit redefining > it. Would you be happy to retain the same builtin defines for FP64 if > changing its behaviour (i.e. __mips_fpr=64)? I think that should be OK. I suppose a natural follow-on question is what __mips_fpr should be for -mfpxx. Maybe just 0? If we want to be extra cautious we could define a second set of macros alongside the old ones. >> The scheme allows an ifunc to request a mode and effectively gives the >> choice to the firstcomer. Every other ifunc then has to live with the >> choice. I don't think that's a good idea, since the order that ifuncs >> are called isn't well-defined or under direct user control. >> >> Since ifuncs would have to live with a choice made by other ifuncs, in >> practice they must all be prepared to deal with FR=1 if linked into a >> fully-modeless or FR1 program, and to deal with FR=0 if linked into a >> fully-modeless or FR0 program. So IMO the dynamic linker should simply >> set FR=1 for modeless programs if the hardware supports it and set it to >> 0 for modeless programs otherwise, like you say in the first paragraph >> of 9.4. > > The ifunc interaction should possibly be moved to a different > proposal. We could reduce this down to a simple statement that > interaction with ifunc needs to be considered when finalising MIPS ifunc > support in general. Sounds good. >> You allow the mode to be changed midexecution if a new FR0 or FR1 object >> is loaded. Is it really worth supporting that though? >> It has the same problem as the ifuncs: once you've dlopen()ed an object, >> you fix the mode for the whole program, even after the dlclose(). >> Unless we know of specific cases where this is needed, maybe it would be >> safer to fix the mode before execution based on DT_NEEDED libraries and >> allow the mode of modeless programs to be overridden by an environment >> variable. > > Scanning the entire set of DT_NEEDED libraries would achieve most of > what full dynamic mode switching gives us, it is essentially the first > stage of the dynamic mode switching described in the proposal > anyway. However, I am concerned about excluding dlopen()ed objects from > mode selection though (not so worried about excluding ifunc, that could > just fix the mode before resolving the first one). One specific concern > is for Android where I believe we have the situation where native > applications are loaded as (a form of) shared library. This means a mode > requirement can be introduced late on. In an Android environment it is > unlikely to be acceptable to have to do something special to load an > application that happens to have a specific mode requirement so dynamic > selection is useful. This is more of a transitional problem than > anything but making it a smooth process is quite important. I'm also not > sure that there is much more effort required for a dynamic linker to > take account of dlopen()ed objects in addition to DT_NEEDED, changes are > needed in this code regardless. As far as GNU/Linux goes, if we do end up with a function in something like a modeless libm that is implemented as an FR-aware ifunc, that would force the choice to be made early anyway. So we have this very specific case where everything in the initial process is modeless, no ifuncs take advantage of the FR setting, and a dlopen()ed object was compiled as fr0 rather than modeless. I agree it's possible but it seems unlikely. I know nothing about the way Android loading works though. :-) Could you describe it in more detail?
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford writes
> Matthew Fortune writes:
> > All,
> >
> > Imagination Technologies would like to introduce the design of an O32
> > ABI extension for MIPS to allow it to be used in conjunction with MIPS
> > FPUs having 64-bit floating-point registers. This is a wide-reaching
> > design that involves changes to all components of the MIPS toolchain
> > it is being posted to GCC first and will progress on to other tools.
> > This ABI extension is compatible with the existing O32 ABI definition
> > and will not require the introduction of new build variants
> (multilibs).
> >
> > The design document is relatively large and has been placed on the
> > MIPS Compiler Team wiki to facilitate review:
> >
> > http://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinkin
> > g
>
> Looks good to me. It'll be interesting to see whether making the odd-
> numbered call-saved-in-fr0 registers available for frx pays off or
> whether it ends up being better to avoid them.
Indeed, I suspect they should be avoided except for leaf functions. You would
have to be pretty desperate for a register if you use the caller-and-callee
save registers!
> I understand the need to deprecate the current -mgp32 -mfp64 behaviour.
> I don't think we should deprecate -mfp64 itself though. Instead, why
> not keep -mfp32 as meaning FR0, -mfp64 meaning FR1 and add -mfpxx for
> modeless? So rather than deprecating the -mgp32 -mfp64 combination and
> adding -mfr, we'd just make -mgp32 -mfp64 generate the new FR1 form in
> which the odd-numbered registers are call-clobbered rather than the old
> form in which they were call-saved.
Extreme caution is the only reason why the design avoided changing fp64
behaviour (basically in case anyone had serious objection). If you would be
happy with a change of behaviour for -mgp32 -mfp64 then that is a great start.
> AIUI the old form never really worked reliably due to things like
> newlib's setjmp not preserving the odd-numbered registers, so it doesn't
> seem worth keeping around. Also, the old form is identified by the GNU
> attribute (4, 4) so it'd be easy for the linker to reject links between
> the old and the new form.
That is true. You will have noticed a number of changes over recent months to
start fixing fp64 as currently defined but having found this new solution then
such fixes are no longer important. The lack of support for gp32 fp64 in linux
is further reason to permit redefining it. Would you be happy to retain the
same builtin defines for FP64 if changing its behaviour (i.e. __mips_fpr=64)?
> The corresponding asm would then be ".set fp=xx".
>
> Either way, a new .set option would be better than a specific .fr
> directive because it gives you access to the option stack (".set
> push"/".set pop").
>
> I'm not sure about:
>
> If an assembly directive is seen prior to the start of the text
> section then this modifies the default mode for the module.
>
> This isn't how any of the existing options work and I think the
> inconsistency would be confusing. It also means that if the first
> function in a file happens to force a local mode (e.g.
> because it's an ifunc implementation) then you'd have to remember to
> write:
>
> .fr x
> .fr 1
>
> so that the first sets the mode for the module and the second sets it
> for the first function. The different treatment of the two lines
> wouldn't be obvious at first glance.
>
> How about instead having a separate directive that explicitly sets the
> global value of an option? I.e. something like ".module", taking the
> same options as ".set". Better names welcome. :-)
Use of a different directive to actually affect the overall mode of a module
sounds like a good plan and it avoids the weird behaviour. The only thing
specifically needed is that the assembly file records the mode it was written
for. Getting the wrong command line option would otherwise lead to unusual
runtime failures. We have been/are still discussing this point so it's no
surprise you have commented on it too. I'll wait for any further comments on
this area and update accordingly.
> The scheme allows an ifunc to request a mode and effectively gives the
> choice to the firstcomer. Every other ifunc then has to live with the
> choice. I don't think that's a good idea, since the order that ifuncs
> are called isn't well-defined or under direct user control.
>
> Since ifuncs would have to live with a choice made by other ifuncs, in
> practice they must all be prepared to deal with FR=1 if linked into a
> fully-modeless or FR1 program, and to deal with FR=0 if linked into a
> fully-modeless or FR0 program. So IMO the dynamic linker should simply
> set FR=1 for modeless programs if the hardware supports it and set it to
> 0 for modeless programs otherwise, like you say in the first paragraph
> of 9.4.
The ifunc interaction should possibly be moved to a different proposal. We
could reduce this down to a simple statem
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune writes:
> All,
>
> Imagination Technologies would like to introduce the design of an O32
> ABI extension for MIPS to allow it to be used in conjunction with MIPS
> FPUs having 64-bit floating-point registers. This is a wide-reaching
> design that involves changes to all components of the MIPS toolchain it
> is being posted to GCC first and will progress on to other tools. This
> ABI extension is compatible with the existing O32 ABI definition and
> will not require the introduction of new build variants (multilibs).
>
> The design document is relatively large and has been placed on the MIPS
> Compiler Team wiki to facilitate review:
>
> http://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
Looks good to me. It'll be interesting to see whether making the
odd-numbered call-saved-in-fr0 registers available for frx pays off
or whether it ends up being better to avoid them.
I understand the need to deprecate the current -mgp32 -mfp64 behaviour.
I don't think we should deprecate -mfp64 itself though. Instead,
why not keep -mfp32 as meaning FR0, -mfp64 meaning FR1 and add -mfpxx
for modeless? So rather than deprecating the -mgp32 -mfp64 combination
and adding -mfr, we'd just make -mgp32 -mfp64 generate the new FR1 form
in which the odd-numbered registers are call-clobbered rather than the
old form in which they were call-saved.
AIUI the old form never really worked reliably due to things like
newlib's setjmp not preserving the odd-numbered registers, so it doesn't
seem worth keeping around. Also, the old form is identified by the
GNU attribute (4, 4) so it'd be easy for the linker to reject links
between the old and the new form.
The corresponding asm would then be ".set fp=xx".
Either way, a new .set option would be better than a specific .fr directive
because it gives you access to the option stack (".set push"/".set pop").
I'm not sure about:
If an assembly directive is seen prior to the start of the text
section then this modifies the default mode for the module.
This isn't how any of the existing options work and I think the
inconsistency would be confusing. It also means that if the
first function in a file happens to force a local mode (e.g.
because it's an ifunc implementation) then you'd have to remember
to write:
.fr x
.fr 1
so that the first sets the mode for the module and the second sets
it for the first function. The different treatment of the two lines
wouldn't be obvious at first glance.
How about instead having a separate directive that explicitly sets the
global value of an option? I.e. something like ".module", taking the
same options as ".set". Better names welcome. :-)
The scheme allows an ifunc to request a mode and effectively gives
the choice to the firstcomer. Every other ifunc then has to live
with the choice. I don't think that's a good idea, since the order
that ifuncs are called isn't well-defined or under direct user control.
Since ifuncs would have to live with a choice made by other ifuncs,
in practice they must all be prepared to deal with FR=1 if linked
into a fully-modeless or FR1 program, and to deal with FR=0 if
linked into a fully-modeless or FR0 program. So IMO the dynamic
linker should simply set FR=1 for modeless programs if the hardware
supports it and set it to 0 for modeless programs otherwise,
like you say in the first paragraph of 9.4.
You allow the mode to be changed midexecution if a new FR0 or FR1
object is loaded. Is it really worth supporting that though?
It has the same problem as the ifuncs: once you've dlopen()ed
an object, you fix the mode for the whole program, even after
the dlclose(). Unless we know of specific cases where this is needed,
maybe it would be safer to fix the mode before execution based on
DT_NEEDED libraries and allow the mode of modeless programs to be
overridden by an environment variable.
If we do end up using ELF flags then maybe adding two new
EF_MIPS_ABI enums would be better. It's more likely to be
trapped by old loaders and avoids eating up those precious
remaining bits.
You didn't say specifically how a static program's crt code would
know whether it was linked as modeless or in a specific FR mode.
Maybe the linker could define a special hidden symbol?
Thanks,
Richard
