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 20:08:23 +0100 (CET)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Andi Kleen <ak@linux.intel.com>
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
In-Reply-To: <20190327154522.GV18020@tassilo.jf.intel.com>
Message-ID: <alpine.DEB.2.21.1903271958320.1789@nanos.tec.linutronix.de>
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>
 <20190327154522.GV18020@tassilo.jf.intel.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 27 Mar 2019, Andi Kleen wrote:
> > 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.

There is no top level assembly anymore. It's static data in the .rodata
section which is completely uninteresting for a call graph. That data is
accessed by the C function.

It's static so it's scope is within the file and whatever GCC does with
that C function it has to respect that it accesses static data. If that's
not true then this really needs to be fixed at the compiler side and not in
the kernel.

Thanks,

	tglx