Re: Fixing the ELF priorities

[David Holland <dholland-tech%netbsd.org@localhost>]

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.

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.

-- 
David A. Holland
dholland%netbsd.org@localhost