On Thu, Jul 29, 2021 at 05:03:34PM +0100, Mark Brown wrote:
On Thu, Jul 29, 2021 at 02:27:04PM +0100, Dave P Martin wrote:
On Thu, Jul 29, 2021 at 12:22:17PM +0100, Mark Brown wrote:
Yeah, it doesn't seem to be in the slightest bit idiomatic for the arm64 asm code the kernel has. I don't know if you think it's worth adding that to SYM_FUNC_START now we have it though?
Actually, I think the core definition of SYM_FUNC_END() in <linux/linkage.h> does this.
Ah, so it does.
It would be good to pick up the common linkage macros; if we have to sprinkle .type manually all over the tests people will likely make mistakes, to that's probably not worth it.
If picking up the macros isn't trivial to do, I guess it's not that important at this stage.
They're not exported from the kernel at all at the minute so that'd be a whole new block of work that feels out of scope here, we already have a stack of asm code in selftests.
Agreed. Feels like it might be a good idea at some point, but it's orthogonal to this series, and for now nothing breaks.
that those are outside the kernel either. We will have to do something like that if anyone starts building userspace with BTI though (or I might just shove a BTI C in there unconditionally, I'm sure we'll cope with the overhead on older systems).
I thought about that, but that .S file isn't annotated as supporting BTI, so I guess there's no problem for now(?)
True, we'll generate linker warnings but it should otherwise sort itself out unless someone forced BTI mode. The whole annotation thing really isn't fun to deal with for assembly code, hopefully there'll be some toolchain improvements in this area at some point.
Ack
Cheers ---Dave