linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linuxppc-dev@lists.ozlabs.org
Subject: [Bug 204125] New: FTBFS on ppc64 big endian and gcc9 because of -mcall-aixdesc and missing __linux__
Date: Wed, 10 Jul 2019 13:24:01 +0000	[thread overview]
Message-ID: <bug-204125-206035@https.bugzilla.kernel.org/> (raw)

https://bugzilla.kernel.org/show_bug.cgi?id=204125

            Bug ID: 204125
           Summary: FTBFS on ppc64 big endian and gcc9 because of
                    -mcall-aixdesc and missing __linux__
           Product: Platform Specific/Hardware
           Version: 2.5
    Kernel Version: any
          Hardware: PPC-64
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: high
          Priority: P1
         Component: PPC-64
          Assignee: platform_ppc-64@kernel-bugs.osdl.org
          Reporter: linux@octaforge.org
        Regression: No

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

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.

For now I worked around it in my distro by explicitly adding `-D__linux__` in
the kbuild where `-mcall-aixdesc` is inserted into flags, and it works, but
that's obviously just a workaround.

I'm not sure what the proper fix would be.

Also, is there any reason not to allow an ELFv2 kernel to be built on big
endian? 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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

             reply	other threads:[~2019-07-10 13:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10 13:24 bugzilla-daemon [this message]
2019-07-10 15:37 ` [Bug 204125] FTBFS on ppc64 big endian and gcc9 because of -mcall-aixdesc and missing __linux__ bugzilla-daemon
2019-07-10 15:41 ` bugzilla-daemon
2019-07-10 15:57 ` bugzilla-daemon
2019-07-10 16:01 ` bugzilla-daemon
2019-07-10 16:04 ` bugzilla-daemon
2019-07-12  1:41 ` bugzilla-daemon
2019-07-12  2:11 ` bugzilla-daemon
2019-07-12 15:36 ` bugzilla-daemon
2019-09-08 14:57 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-204125-206035@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).