https://bugzilla.kernel.org/show_bug.cgi?id=204125
Segher Boessenkool (seg...@kernel.crashing.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |seg...@kernel.crashing.org
--- Comment #1 from Segher Boessenkool (seg...@kernel.crashing.org) ---
(In reply to Daniel Kolesa from comment #0)
> On ppc64 big endian, the kernel builds with `-mcall-aixdesc` which since gcc
> 9.x removes `__linux__` from the list of macros being defined.
This is a bug. Please report at https://gcc.gnu.org/bugzilla .
> This behavior
> is supposed to be more correct (as it's in this case nothing but a hack, the
> flag should apparently only be used when building for AIX)
What makes you think that?
OTOH, why does the kernel use that option?
> but sadly it
> breaks build since several things within the tree rely on `__linux__` being
> defined and `#ifdef` some of their code based on said macro.
Those are bugs as well, then.
> Just removing `-mcall-aixdesc` (and using just `-mabi=elfv1`) is however not
> enough, as that instead causes countless undefined references to just about
> every symbol when linking `vmlinux`. It would seem that `-mcall-aixdesc`
> changes the way symbols are declared in a way that is not expected.
> Little endian is not affected because that one uses `-mabi=elfv2`
> exclusively.
Of course, that is the only defined ABI for powerpc64le after all.
> Also, is there any reason not to allow an ELFv2 kernel to be built on big
> endian?
Building it _on_ BE works just fine, of course. But you mean building a BE
kernel using the ELFv2 ABI. This is not supported; it would require writing
other versions for various low-level things.
ELFv2 is not supported in BE userland, either, btw.
> There are some supposed performance benefits, and ELFv2 itself
> supports either endianness. The current kbuild logic pretty much forces
> ELFv1 for big endian and ELFv2 for little endian.
ELFv2 has a few little benefits; it is newer, there were lessons learnt. It
would be surprising if it has better than trivial advantages for the BE kernel
though. But feel free to try, of course :-)
--
You are receiving this mail because:
You are watching the assignee of the bug.
