[herbertx/cryptodev] crypto: arm64/poly1305 - move data to rodata section (47d9625)

[Justin He]

Hi Andy,

> -----Original Message-----
> From: Herbert Xu <herbert at gondor.apana.org.au>
> Sent: Saturday, August 3, 2024 8:40 AM
> To: herbertx/cryptodev
> <reply+AAIFISMST74UQEQBJUWW7J6EXDLZNEVBMPHARJBRSY at reply.github.c
> om>
> Cc: herbertx/cryptodev <cryptodev at noreply.github.com>; Author
> <author at noreply.github.com>; Justin He <Justin.He at arm.com>; David S. Miller
> <davem at davemloft.net>; Catalin Marinas <Catalin.Marinas at arm.com>;
> linux-crypto at vger.kernel.org; Will Deacon <will at kernel.org>;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Ard
> Biesheuvel <ardb at kernel.org>; Andy Polyakov <appro at cryptogams.org>
> Subject: Re: [herbertx/cryptodev] crypto: arm64/poly1305 - move data to
> rodata section (47d9625)
> 
> On Fri, Aug 02, 2024 at 08:09:10AM -0700, Andy Polyakov wrote:
> > Formally speaking this is error prone, because there is no guarantee that linker
> will be able to resolve it as argument to `adr` instruction above. I mean since the
> address is resolved with `adr` instruction alone, there is a limit on how far the
> label can be from the instruction in question. On a practical level, if/since it's
> compiled as part of a kernel module, it won't be a problem, because the module
> won't be large enough to break the limit, but it **is** a problem in general case.
Thanks, 
Can this problem be resolved by changing "adr" to "adrp"?

> >
> > But why would objtool attempt to disassemble it? Does it actually attempt to
> disassemble unreferenced spaces between functions? Note that the .Lzeros label
> doesn't make it into .o file, so there won't be anything in the symbol table to
> discover as potential entry point..
There is a similar patch (1253cab8a352) for x86. I guess that objtool/stacktool can be improved in this regard.

--
Cheers,
Justin (Jia He)