On Wed, Jan 13, 2021 at 8:59 AM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > On Tue, Jan 12, 2021 at 09:01:54PM +0000, Mark Brown wrote: > > On Tue, Jan 12, 2021 at 11:46:24AM -0800, Nick Desaulniers wrote: > > > > This: > > > > > when building with LLVM_IAS=1 (Clang's integrated assembler). Josh > > > notes: > > > > > So basically, you can use an .L symbol *inside* a function or a code > > > segment, you just can't use the .L symbol to contain the code using a > > > SYM_*_START/END annotation pair. > > > > is a stronger statement than this: > > > > > + Developers should avoid using local symbol names that are prefixed with > > > + ``.L``, as this has special meaning for the assembler; a symbol entry will > > > + not be emitted into the symbol table. This can prevent ``objtool`` from > > > + generating correct unwind info. Symbols with STB_LOCAL binding may still be > > > + used, and ``.L`` prefixed local symbol names are still generally useable > > > + within a function, but ``.L`` prefixed local symbol names should not be used > > > + to denote the beginning or end of code regions via > > > + ``SYM_CODE_START_LOCAL``/``SYM_CODE_END``. > > > > and seems more what I'd expect - SYM_FUNC* is also affected for example. > > Even though other usages are probably not very likely it seems better to > > keep the stronger statement in case someone comes up with one, and to > > stop anyone spending time wondering why only SYM_CODE_START_LOCAL is > > affected. > > Agreed, I think the comment is misleading/wrong/unclear in multiple > ways. In most cases the use of .L symbols is still fine. What's no > longer fine is when they're used to contain code in any kind of > START/END pair. Apologies, that was not my intention. I've sent a follow up in https://lore.kernel.org/lkml/20210113174620.958429-1-ndesaulniers@xxxxxxxxxx/T/#u since BP picked up v3 in tip x86/entry: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/entry&id=bde718b7e154afc99e1956b18a848401ce8e1f8e -- Thanks, ~Nick Desaulniers
