> Matthew Fortune <matthew.fort...@imgtec.com> 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 requirements cannot be met. We certainly need the extra symbol for bare metal for the crt to set the correct mode but I'm not convinced about taking/needing to take the same approach for linux. I will start updating the design with various points that we have discussed so far that are more clear cut. Regards, Matthew
