[ARM] [bug] Weak Symbols as Function Pointer Fails to be overrided by Strong Symbol

[Zhenhang1213]

test.c

#include <stdio.h>

#pragma GCC visibility push(hidden)

void __attribute__((__weak__)) xxx(void)
{
        printf("weak\n");
}

void call_func(void (*f)(void));

int main()
{
        call_func(xxx);
        return 0;
}

test1.c

#include <stdio.h>

#pragma GCC visibility push(hidden)
void xxx(void)
{
        printf("default\n");
}

void call_func(void (*f)(void))
{
        f();
}

opts:
arm32-clang test.c test1.c -fpic
result:

weak

arm32-gcc test.c test1.c -fpic
result:

default

godbolt:
https://godbolt.org/z/jrT49YKM1

I believe this issue is closely related to how weak symbol function pointers are loaded. How can we fix this problem to align with GCC's behavior?

[llvmbot]

@llvm/issue-subscribers-backend-arm

Author: Austin (Zhenhang1213)

Details

test.c ``` #include <stdio.h>

#pragma GCC visibility push(hidden)

void attribute((weak)) xxx(void)
{
printf("weak\n");
}

void call_func(void (*f)(void));

int main()
{
call_func(xxx);
return 0;
}

test1.c

#include <stdio.h>

#pragma GCC visibility push(hidden)
void xxx(void)
{
printf("default\n");
}

void call_func(void (*f)(void))
{
f();
}

opts:
arm32-clang  test.c test1.c  -static -fpic
result:

weak

arm32-gcc test.c test1.c  -static -fpic
result:

default

godbolt:
https://godbolt.org/z/jrT49YKM1

I believe this issue is closely related to how weak symbol function pointers are loaded. How can we fix this problem to align with GCC's behavior?


</details>

[Zhenhang1213]

cc @davemgreen @smithp35

[Zhenhang1213]

@hstk30-hw

[smithp35]

It is likely that is down to the ARM backend use of R_ARM_REL32 relocation to calculate the offset to the definition. It looks like this is being resolved too early.

xxx:                                    @ @xxx
        push    {r11, lr}
        mov     r11, sp
        ldr     r0, .LCPI0_0
.LPC0_0:
        add     r0, pc, r0
        bl      printf
        pop     {r11, pc}
        .p2align        2
.LCPI0_0:
        .long   .L.str-(.LPC0_0+8)
.Lfunc_end0:

        .hidden main                            @ -- Begin function main
        .globl  main
        .p2align        2
        .type   main,%function
        .code   32
main:                                   @ @main
        .fnstart
        mov     r11, sp
        sub     sp, sp, #8
        ldr     r0, .LCPI1_0
        str     r0, [sp, #4]
        ldr     r0, .LCPI1_1
.LPC1_0:
        add     r0, pc, r0
        bl      call_func
        ldr     r0, .LCPI1_0
        mov     sp, r11
        pop     {r11, pc}
        .p2align        2
.LCPI1_0:
        .long   0                               @ 0x0
.LCPI1_1:
        .long   xxx-(.LPC1_0+8)
.Lfunc_end1:

As both xxx and (.LPC1_0+8) are in the same section the assembler resolves this relocation statically so the linker never sees the weak definition to override it.

If -ffunction-sections is used a relocation is needed which exposes xxx to the linker. I expect that to work.

If you want to look for fixing this, I would start looking in the ARM backend where there's a decision to choose to emit a relocation or resolve the fixup. If the definition of the symbol is weak then the backend should, for the R_ARM_REL32 relocation, emit a relocation rather than resolving it at assembly time.

[smithp35]

My apologies I think I got my diagnosis wrong. Both clang and gcc behave identically when it comes to eagerly resolving the subtraction of weak symbols. There is an existing test test/MC/ELF/weak-diff.s with a commit message that states that clang is following gcc. This is still the case today for at least x86, ARM and AArch64 GNU as.

Looking at the code-generation from GCC

00000000 <xxx>:
       0: e92d4010      push    {r4, lr}
       4: e59f0008      ldr     r0, [pc, #0x8]          @ 0x14 <xxx+0x14>
       8: e08f0000      add     r0, pc, r0
       c: ebfffffe      bl      0xc <xxx+0xc>           @ imm = #-0x8
                        0000000c:  R_ARM_CALL   puts
      10: e8bd8010      pop     {r4, pc}
      14: 04 00 00 00   .word   0x00000004
                        00000014:  R_ARM_REL32  .LC0

00000018 <main>:
      18: e52de004      str     lr, [sp, #-0x4]!
      1c: e24dd00c      sub     sp, sp, #12
      20: e59f3020      ldr     r3, [pc, #0x20]         @ 0x48 <main+0x30>
      24: e08f3003      add     r3, pc, r3
      28: e59f201c      ldr     r2, [pc, #0x1c]         @ 0x4c <main+0x34>
      2c: e7933002      ldr     r3, [r3, r2]
      30: e58d3004      str     r3, [sp, #0x4]
      34: e1a00003      mov     r0, r3
      38: ebfffffe      bl      0x38 <main+0x20>        @ imm = #-0x8
                        00000038:  R_ARM_CALL   call_func
      3c: e3a00000      mov     r0, #0
      40: e28dd00c      add     sp, sp, #12
      44: e49df004      ldr     pc, [sp], #4
      48: 1c 00 00 00   .word   0x0000001c
                        00000048:  R_ARM_BASE_PREL      _GLOBAL_OFFSET_TABLE_
      4c: 00 00 00 00   .word   0x00000000
                        0000004c:  R_ARM_GOT_BREL       xxx

This is using GOT entries for the weak symbol, even though .hidden is used. Clang will use a GOT entry when the symbol has default visibility but not hidden.

I think the better fix is to make sure that the code-generation always uses a GOT entry for hidden weak-references when PIC is used.

[Zhenhang1213]

My apologies I think I got my diagnosis wrong. Both clang and gcc behave identically when it comes to eagerly resolving the subtraction of weak symbols. There is an existing test test/MC/ELF/weak-diff.s with a commit message that states that clang is following gcc. This is still the case today for at least x86, ARM and AArch64 GNU as.

Looking at the code-generation from GCC

00000000 <xxx>:
       0: e92d4010      push    {r4, lr}
       4: e59f0008      ldr     r0, [pc, #0x8]          @ 0x14 <xxx+0x14>
       8: e08f0000      add     r0, pc, r0
       c: ebfffffe      bl      0xc <xxx+0xc>           @ imm = #-0x8
                        0000000c:  R_ARM_CALL   puts
      10: e8bd8010      pop     {r4, pc}
      14: 04 00 00 00   .word   0x00000004
                        00000014:  R_ARM_REL32  .LC0

00000018 <main>:
      18: e52de004      str     lr, [sp, #-0x4]!
      1c: e24dd00c      sub     sp, sp, #12
      20: e59f3020      ldr     r3, [pc, #0x20]         @ 0x48 <main+0x30>
      24: e08f3003      add     r3, pc, r3
      28: e59f201c      ldr     r2, [pc, #0x1c]         @ 0x4c <main+0x34>
      2c: e7933002      ldr     r3, [r3, r2]
      30: e58d3004      str     r3, [sp, #0x4]
      34: e1a00003      mov     r0, r3
      38: ebfffffe      bl      0x38 <main+0x20>        @ imm = #-0x8
                        00000038:  R_ARM_CALL   call_func
      3c: e3a00000      mov     r0, #0
      40: e28dd00c      add     sp, sp, #12
      44: e49df004      ldr     pc, [sp], #4
      48: 1c 00 00 00   .word   0x0000001c
                        00000048:  R_ARM_BASE_PREL      _GLOBAL_OFFSET_TABLE_
      4c: 00 00 00 00   .word   0x00000000
                        0000004c:  R_ARM_GOT_BREL       xxx

This is using GOT entries for the weak symbol, even though .hidden is used. Clang will use a GOT entry when the symbol has default visibility but not hidden.

I think the better fix is to make sure that the code-generation always uses a GOT entry for hidden weak-references when PIC is used.

yes, I have observed this difference before; I found that clang uses the R_ARM_GOT_PREL type of relocation when the symbol has default visibility, while gcc uses R_ARM_GOTPC and R_ARM_GOT32. The code I modified is here:

llvm-project/llvm/lib/Target/ARM/ARMFastISel.cpp

Lines 3037 to 3045 in 89d8fe9

	Register ARMFastISel::ARMLowerPICELF(const GlobalValue *GV, MVT VT) {
	bool UseGOT_PREL = !GV->isDSOLocal();
	LLVMContext *Context = &MF->getFunction().getContext();
	unsigned ARMPCLabelIndex = AFI->createPICLabelUId();
	unsigned PCAdj = Subtarget->isThumb() ? 4 : 8;
	ARMConstantPoolValue *CPV = ARMConstantPoolConstant::Create(
	GV, ARMPCLabelIndex, ARMCP::CPValue, PCAdj,
	UseGOT_PREL ? ARMCP::GOT_PREL : ARMCP::no_modifier,
	/*AddCurrentAddress=*/UseGOT_PREL);

I change to
bool UseGOT_PREL = !GV->isDSOLocal() || GV->hasWeakLinkage();
I will update my PR a bit later.

[MaskRay]

[ARM] [bug] Weak Symbols as Function Pointer Fails to be overrided by Strong Symbol

I believe this is a GCC inconsistency specific to the ARM target, rather than a Clang bug.

#pragma GCC visibility push(hidden)
__attribute__((weak)) void weak_hidden(void) {}
#pragma GCC visibility pop

__attribute__((weak)) void weak_default(void) {}

void *get_weak_hidden(void) { return (void*)weak_hidden; }
void *get_weak_default(void) { return (void*)weak_default; }

gcc's x86_64, aarch64, and riscv64 targets generate a PC-relative code sequence for weak_hidden while its arm port generates GOT indirection.

For hidden undefined weak symbols, clang and gcc are consistent in generating GOT indirection.

Target	Case	Clang	GCC	Match?
x86_64	def hidden	PC-rel	PC-rel	Yes
x86_64	def default	GOT	GOT	Yes
x86_64	decl hidden	GOT	GOT	Yes
x86_64	decl default	GOT	GOT	Yes
aarch64	def hidden	PC-rel	PC-rel	Yes
aarch64	def default	GOT	GOT	Yes
aarch64	decl hidden	GOT	GOT	Yes
aarch64	decl default	GOT	GOT	Yes
arm	def hidden	PC-rel	GOT	No
arm	def default	GOT	GOT	Yes
arm	decl hidden	GOT	GOT	Yes
arm	decl default	GOT	GOT	Yes
riscv64	def hidden	PC-rel	PC-rel	Yes
riscv64	def default	GOT	GOT	Yes
riscv64	decl hidden	GOT	GOT	Yes
riscv64	decl default	GOT	GOT	Yes

[hstk30-hw]

@pinskia

[pinskia]

Have you looked to see what the old arm compilers do? The ones pre llvm?
Also I am not sure if gcc or binutils.
Have you tried using the assembly output from gcc with llvm as and seeing the behavior?

[Zhenhang1213]

Have you looked to see what the old arm compilers do? The ones pre llvm? Also I am not sure if gcc or binutils. Have you tried using the assembly output from gcc with llvm as and seeing the behavior?

I use llvm 15.0.4, gcc 7.3.0 or 14.3.0, binutils 2.41. while I use clang compiler assembly from gcc, printf "default", it's expected behavior. However, I using llvm with gnu-as, printf "weak"