[PATCH v3 2/2] arm64: Unconditionally override SYM_FUNC macros

Ard Biesheuvel ardb at kernel.org
Tue Dec 14 06:12:01 PST 2021


On Tue, 14 Dec 2021 at 15:10, Will Deacon <will at kernel.org> wrote:
>
> On Mon, Dec 13, 2021 at 07:21:25PM +0000, Mark Brown wrote:
> > On Mon, Dec 13, 2021 at 06:46:54PM +0000, Will Deacon wrote:
> > > On Wed, Dec 08, 2021 at 04:08:19PM +0000, Mark Brown wrote:
> >
> > > > --- a/arch/arm64/include/asm/linkage.h
> > > > +++ b/arch/arm64/include/asm/linkage.h
> > > > @@ -8,10 +8,18 @@
> > > >
> > > >  #define BTI_C bti c ;
> > > >
> > > > +#else
> > > > +
> > > > +#define BTI_C
> > > > +
> > > > +#endif
> >
> > > Why do we need this hunk? Having the hint instruction should be fine, no?
> >
> > We could unconditionally insert the hint but that would be a step back
> > from what we currently have and would mean that hand written assembly
> > would be that little bit worse than what the compiler outputs.  If this
> > had been causing us issues I could see simplifying but I'm not aware of
> > any - the issues I'm aware of have been due to not adding the landing
> > pads in SYM_CODE, not SYM_FUNC.
>
> I don't have a strong opinion here, so whatever you like. I just tend to
> think that most people will have BTI enabled and there's something to be
> said for having an instruction always emitted when you have a token in
> assembly code.
>

+1

I already pointed out computed gotos, which are admittedly rare, but
there are other reasons why adhering to WYSIWYG is strongly preferred
for asm code IMO.



More information about the linux-arm-kernel mailing list