lkml.org 
[lkml]   [2020]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] objtool: ignore .L prefixed local symbols
    On Thu, Feb 13, 2020 at 11:20:55AM -0800, Fangrui Song wrote:
    > On 2020-02-13, Nick Desaulniers wrote:
    > >Top of tree LLVM has optimizations related to
    > >-fno-semantic-interposition to avoid emitting PLT relocations for
    > >references to symbols located in the same translation unit, where it
    > >will emit "local symbol" references.
    > >
    > >Clang builds fall back on GNU as for assembling, currently. It appears a
    > >bug in GNU as introduced around 2.31 is keeping around local labels in
    > >the symbol table, despite the documentation saying:
    > >
    > >"Local symbols are defined and used within the assembler, but they are
    > >normally not saved in object files."
    >
    > If you can reword the paragraph above mentioning the fact below without being
    > more verbose, please do that.
    >
    > If the reference is within the same section which defines the .L symbol,
    > there is no outstanding relocation. If the reference is outside the
    > section, there will be an R_X86_64_PLT32 referencing .L
    >

    Can you describe what case the clang change is supposed to optimize?
    AFAICT, it kicks in when the symbol is known by the compiler to be local
    to the DSO and defined in the same translation unit.

    But then there are two cases:
    (a) we have call foo, where foo is defined in the same section as the
    call instruction. In this case the assembler should be able to fully
    resolve foo and not generate any relocation, regardless of whether foo
    is global or local.
    (b) we have call foo, where foo is defined in a different section from
    the call instruction. In this case the assembler must generate a
    relocation regardless of whether foo is global or local, and the linker
    should eliminate it.

    In what case does does replacing call foo with call .Lfoo$local help?

    \
     
     \ /
      Last update: 2020-02-14 07:17    [W:2.612 / U:1.224 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site