Hi Andy, > -----Original Message----- > From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Sent: Saturday, August 3, 2024 8:40 AM > To: herbertx/cryptodev > <reply+AAIFISMST74UQEQBJUWW7J6EXDLZNEVBMPHARJBRSY@reply.github.c > om> > Cc: herbertx/cryptodev <cryptodev@xxxxxxxxxxxxxxxxxx>; Author > <author@xxxxxxxxxxxxxxxxxx>; Justin He <Justin.He@xxxxxxx>; David S. Miller > <davem@xxxxxxxxxxxxx>; Catalin Marinas <Catalin.Marinas@xxxxxxx>; > linux-crypto@xxxxxxxxxxxxxxx; Will Deacon <will@xxxxxxxxxx>; > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Ard > Biesheuvel <ardb@xxxxxxxxxx>; Andy Polyakov <appro@xxxxxxxxxxxxxx> > 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)
