Re: Fixing the ELF priorities

[Maxime Villard <max%M00nBSD.net@localhost>]

Le 03/07/2014 21:40, David Holland a écrit :
> 
> On Thu, Jul 03, 2014 at 03:26:09PM +0200, Maxime Villard wrote:
>  > > Being able to automatically invoke a suitable emulator for user
>  > > binaries of the wrong OS and/or architecture would be very helpful for
>  > > crossbuilding difficult packages.
>  > 
>  > But this isn't related to the priority problem, right?
> 
> Right, I think Justin mentioned it just because it was worth
> mentioning and tangentially related.
> 
>  > Perhaps I haven't been clear enough; the question is:
>  > 
>  >   - exec_elf32 is a module, and is enabled with EXEC_ELF32 (#define).
>  >   - exec_elf32 (module) is dormant on 64bit systems.
>  >   - linux32 and netbsd32 *don't need* exec_elf32 (module), but need
>  >     EXEC_ELF32 (#define).
>  >   - my plan is to keep EXEC_ELF32 defined on 64bit systems, but to disable
>  >     exec_elf32 (module).
>  >   - Problem: linux32 has exec_elf32 (module) as dependency.
>  >   - Question: do I remove this dependency, given the fact that netbsd32
>  >     too does not have it?
> 
> Well ok. It looks to me like the problem is that the EXEC_ELF32 and
> EXEC_ELF64 code each provides a "native" struct execsw entry, but
> obviously only one of them can be native at once so the other one
> won't ever work.
> 
> It seems like the solution, then, is to take the "native" struct
> execsw entries out of the EXEC_ELF32 and EXEC_ELF64 code, and instead
> always provide a single native struct execsw entry in exec_elf.c based
> on ARCH_ELFSIZE. That will always work for native binaries, and a
> 64-bit machine with compat32 (of whatever flavor) will load one or
> more additional execsw entries via compat32 that use compat32.
> 
> And then the compat_linux32, compat_netbsd32, etc. can all depend on
> the EXEC_ELF32 module like they need to.

Yes. Normally there should be one, native exec_elf module, and another
exec_elf32 for linux32 and netbsd32.

But exec_elf{32/64} also compile core_elf{32/64}.c, and they all rely
on ELFSIZE, EXEC_ELF32/EXEC_ELF64, ARCH_ELFSIZE, etc, that are defined
everywhere and nowhere. It is not clear to me how all these #defines are
supposed to work.

> 
> AIUI, btw, it is wrong for this dependency to depend on whether
> EXEC_ELF32 is defined during compilation; theoretically if EXEC_ELF32
> is compiled into the kernel the module should still depend on it and
> will still "load" it properly. (However, it's possible that the reason
> such logic is in place is that this doesn't actually work in
> practice.)
> 
> The question is whether taking the "native" execsw entries out of the
> EXEC_ELF32 and EXEC_ELF64 code will break the module system. I'm not
> clear on this.
> 

I don't think it would break the module system. But this big change will
surely break something else. That's why I wanted to keep the current
architecture and just remove exec_elf32 on 64bit systems, for the moment.