This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: as: How to determine the section of symbols
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Peter Zijlstra <peterz at infradead dot org>
- Cc: Binutils <binutils at sourceware dot org>, Josh Poimboeuf <jpoimboe at redhat dot com>
- Date: Mon, 15 Jul 2019 13:10:42 -0700
- Subject: Re: as: How to determine the section of symbols
- References: <20190715144844.GJ3419@hirez.programming.kicks-ass.net>
On Mon, Jul 15, 2019 at 7:48 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> Hi all,
>
> I'm trying to 'optimize' the Linux Kernel x86 jump_label support. That
> is; jump_label or static_branch() is a Linux Kernel construct build upon
> GCC asm goto and provides for self-modifying code based branches.
> Regular execution will only see unconditional branches or nops.
>
> Currently, on x86, we patch between jmp.d32 or nop5 and this works well.
>
> The quest is to also allow usage of jmp.d8 (and the matching nop2) where
> the displacement allows for this.
>
> The below patch is the last of a series that implements this and
> contains all the relevant bits to this discussion, and is subtly broken.
>
> The problem is that the labels GCC hands to the asm goto () can be in
> different sections (namely .text and .text.unlikely), and the GAS manual
> sayeth:
>
> [ https://sourceware.org/binutils/docs-2.27/as/Infix-Ops.html#Infix-Ops ]
>
> - Subtraction. If the right argument is absolute, the result has the
> section of the left argument. If both arguments are in the same
> section, the result is absolute. You may not subtract arguments from
> different sections.
>
> Funnily this does not result in a compile/assemble time error :-(, it
> seems to emit a MOP5 but then at runtime explodes because the actual
> displacement (after linking etc..) ends up fitting in a d8 and then the
> actual code and the expected code don't match up at code patching time
> and we BUG.
>
> If I were to be able to reliably detect this section mismatch I could
> encode it in the JUMP_TABLE_ENTRY (__jump_table section).
>
> Any clues on how I can (best) fix this; even if it involves writing a
> GAS patch that'd be fine, we can have this functionality depend on a
> binutils version.
>
.d8 is only a hint. Is that possible to use the new ".nops SIZE" directive
where SIZE can be an expression.
--
H.J.