[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <cf7449c2-71ef-aed1-c871-c9ae7202b3fc@rasmusvillemoes.dk>
Date: Wed, 6 Apr 2022 10:30:32 +0200
From: Rasmus Villemoes <linux@...musvillemoes.dk>
To: Thomas Gleixner <tglx@...utronix.de>,
Alexey Dobriyan <adobriyan@...il.com>,
Peter Zijlstra <peterz@...radead.org>
Cc: x86@...nel.org, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, hpa@...or.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] x86/alternative: record .altinstructions section
entity size
On 05/04/2022 21.24, Thomas Gleixner wrote:
> On Sun, Mar 13 2022 at 21:05, Alexey Dobriyan wrote:
> That does not matter. M merges any duplications in sections with the
> same [section] name, entity size and flags.
>
> .pushsection .bar "aM" @progbits, 4
> .byte 0x01, 0x02, 0x03, 0x04
> .popsection
>
> .pushsection .bar "aM" @progbits, 4
> .byte 0x01, 0x02, 0x03, 0x04
> .popsection
>
> Will create a section .bar with lenght 4 and the content:
> 0x1,0x2,0x3,0x4
>
> What saves you here is the fact that the altinstruction entries are
> guaranteed to be unique, but that wants a big fat comment.
Actually, I think what saves this is that the linker at least currently
ignores the merge flag for sections with relocations; from binutils
bfd/merge.c:
if ((sec->flags & SEC_RELOC) != 0)
{
/* We aren't prepared to handle relocations in merged sections. */
return true;
}
I do think it is theoretically possible for two altinstruction entries
to end up being identical after relocations have been applied (same
relative offsets to both the .text section and their replacement
instructions).
Rasmus
Powered by blists - more mailing lists