[PATCH v2 2/7] linkage: add SYM_{ENTRY,START,END}_AT()

[Mark Rutland]

On Fri, Feb 11, 2022 at 11:32:27AM +0000, Mark Rutland wrote:
> On Thu, Feb 10, 2022 at 05:20:10PM -0800, Nick Desaulniers wrote:
> > On Thu, Feb 10, 2022 at 6:52 AM Mark Rutland <mark.rutland at arm.com> wrote:
 > For the expression
> > 
> > > .if (qwerty_fiqin_end - qwerty_fiqin_start) > (0x200 - 0x1c)
> > 
> > can you use local labels (`.L` prefix) rather than symbolic
> > references? or is there a risk of them not being unique per TU?
>
> For the problem in this patch I might be able to do something of that shape,
> but I'll need to factor the SYM_*() helpers differently so that I can use
> labels for the primary definition.

FWIW, that refactoring turned out to be easier than I expected, and I actually
prefer the new structure.

I've ended up dropping this patch, and in the next patch I leave
SYM_FUNC_START() unchanged, but calculate the size in SYM_FUNC_END() and
propagate that to all the aliases pre-calculated:

diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index dbf8506decca..027ab1618bf8 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -165,7 +165,18 @@
 #ifndef SYM_END
 #define SYM_END(name, sym_type)                                \
        .type name sym_type ASM_NL                      \
-       .size name, .-name
+       .set .L__sym_size_##name, .-name ASM_NL         \
+       .size name, .L__sym_size_##name
+#endif
+
+/* SYM_ALIAS -- use only if you have to */
+#ifndef SYM_ALIAS
+#define SYM_ALIAS(alias, name, sym_type, linkage)                      \
+       linkage(alias) ASM_NL                                           \
+       .set alias, name                                                \
+       .type alias sym_type ASM_NL                                     \
+       .set .L__sym_size_##alias, .L__sym_size_##name ASM_NL           \
+       .size alias, .L__sym_size_##alias
 #endif

I still think that in future we *might* want to be able to use two non-label
symbols (in the same section/fragment/etc) to generate an absolute expression,
but that's not a blocker for this series, and for the common cases (e.g.
checking size) we can probably work around that as above.

Thanks for looknig at this!

Mark.