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.
