https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92030
--- Comment #2 from Alexander Nikulin <anikulin at dlink dot ru> ---
(In reply to Richard Biener from comment #1)
> You're doing it behind the back of the compiler - maybe use
> __attribute__((alias("abc1"))) instead?
Hi Richard,
yes, I did.
It declares global symbol 'abc2':
-----------------------------------------
-#APP
- .equiv abc2, abc1
-
+ .globl abc2
+ abc2 = abc1
.rdata
.align 2
-----------------------------------------
00411010 d abc1
00411010 D abc2
^
and it works with my snippet:
@abc1 = 0x411010, abc2 = 0x411010, @abc2 = 0x411010
But as I understood, the developers would like to have a static alias-symbol
exactly.
Building FRR with __attribute__((alias(...))):
extern struct memtype MTYPE_##name[1] __attribute__((alias("_mt_" #name)));
produces the expected:
.../grammar_sandbox.c:38: multiple definition of `MTYPE_CMD_TOKENS'
.../command_graph.c:29: first defined here
Am agreed that the .equiv trick may be treated as a hack, but I can not offer a
valid replacement. And it works fine on
x86_64: (Debian 8.2.0-16),
i686: (Debian 6.3.0-18+deb9u1),
very ancient xscale/armv5b: (gcc-4.4.3).
Now I have no aarch64 board to check a compiled binary, but I see LO calls for
abc2 in the generated asm.
If this is not a compiler bug but wrong coding approach, could you please offer
the decision which provides "static" aliases?
Thanks!
