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.
> 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
