[lkml]   [2021]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v4] x86/entry: emit a symbol for register restoring thunk
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
> 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

> This also looks like a good candiate for a checkpatch rule, but that can
> be done separately of course.

I like the idea of a checkpatch rule.


 \ /
  Last update: 2021-01-13 18:03    [W:0.086 / U:2.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site