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:   Tue, 26 Mar 2019 23:25:45 +0100 (CET)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Andi Kleen <ak@linux.intel.com>
cc:     Andi Kleen <andi@firstfloor.org>, x86@kernel.org,
        akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/17] x86, lto: Mark all top level asm statements as
 .text
In-Reply-To: <20190326213803.GN18020@tassilo.jf.intel.com>
Message-ID: <alpine.DEB.2.21.1903262321390.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>
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

Andi.

On Tue, 26 Mar 2019, Andi Kleen wrote:
> On Tue, Mar 26, 2019 at 06:03:59PM +0100, Thomas Gleixner wrote:
> > On Thu, 21 Mar 2019, Andi Kleen wrote:
> > 
> > > With gcc 8 toplevel assembler statements that do not mark themselves
> > > as .text may end up in other sections.
> > 
> > Which is clearly a change in behaviour. Is that intended or just yet
> > another feature of GCC?
> 
> I'm not sure it's a new behavior, but I've seen it first
> with gcc 8.

Ok.
 
> > Your subject says: 'x86, lto:'
> > 
> > So is this a LTO related problem or is the section randomization
> > independent of LTO?
> 
> The basic behavior is independent of LTO, but I've only seen
> failures with LTO. But I believe in theory it could lead
> to failures even without LTO.

Well, we better should know the real reason for this wreckage. I mean, the
default section for text is suprisingly .text. I don't see a reason why
this would be any different for an assembly function implemented in a C
file.

So the question is whether GCC does something silly in general which gets
'repaired' silentely by the linker or whether it's just an LTO issue.

If it's the former, then we must backport those fixes.

Could you please verify with the GCC people as you seem to have a
reproducer of some sort.

Thanks,

	tglx