Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 27 Mar 2019 08:45:22 -0700
From:   Andi Kleen <ak@linux.intel.com>
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Andi Kleen <andi@firstfloor.org>, x86@kernel.org,
        Andrew Morton <akpm@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [PATCH 02/17] x86, lto: Mark all top level asm statements as
 .text
Message-ID: <20190327154522.GV18020@tassilo.jf.intel.com>
References: <20190321220009.29334-1-andi@firstfloor.org>
 <20190321220009.29334-3-andi@firstfloor.org>
 <alpine.DEB.2.21.1903261751490.1789@nanos.tec.linutronix.de>
 <20190326213803.GN18020@tassilo.jf.intel.com>
 <alpine.DEB.2.21.1903262321390.1789@nanos.tec.linutronix.de>
 <20190327005523.bbxxittqf4d5bdz5@two.firstfloor.org>
 <alpine.DEB.2.21.1903270820530.1789@nanos.tec.linutronix.de>
 <20190327145918.GU18020@tassilo.jf.intel.com>
 <alpine.DEB.2.21.1903271600050.1789@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.21.1903271600050.1789@nanos.tec.linutronix.de>
User-Agent: Mutt/1.11.3 (2019-02-01)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> Why on earth is this needed for LTO?
> 
> From the GCC manual:
> 
>  "This attribute, attached to a global variable or function, nullifies the
>   effect of the -fw hole-program command-line option, so the object remains
>   visible outside the current compilation unit."
> 
> Neither the variable nor the data generated are global anymore. This data
> is only used inside this compilation unit and I don't see why LTO needs a
> reference outside of it. If so, then I really want to understand WHY
> exactly.

The LTO code generation doesn't compile file by file, but reorders
all the functions and other top level statements into "partitions".
The partitions are ordered by call graph so that inlining and some
other optimizations work efficiently

Then it finally runs multiple copies of the gcc code generator that
generate code from these partitions, each generating an own assembler file.

The top level assembler is not part of the call graph that drives
the partitioning.

So it can happen (in fact it's likely) that the top level assembler
statement ends up in a different partition and final assembler file
than the other functions in the same source file.

The repartitioning handles all symbols that are visible to C
automatically.

But for top level asm() referencing C symbols gcc doesn't know what
it is referenced.

Normally in non LTO it just works because everything ends up 
in the same assembler file and the assembler can resolve the static label.

But that won't work if it's in a different assembler file,
as in LTO.

Fixing it would probably require adding some new syntax to top
level asm to declare symbols it referenced, so that gcc understands
the references.

But if we make it __visible and global it works too because
the linker resolves it. That's simple enough, although can be a bit
unexpected.

More information on LTO internals:
https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html#LTO-Overview

-Andi