-fno-plt option does not suppress PLT generation in Clang 19 dev, while GCC works as expected

[lfeng14]

Environment

• Arch: aarch64
• Clang Version: Clang 19 dev (e.g., clang version 19.0.0git)
• GCC Version: (e.g., gcc version 10.3)
• Compiler Flags: -fno-plt

Description:

I encountered an issue with the -fno-plt option in Clang 19 dev (development version) on aarch64. When compiling code with -fno-plt, Clang still generates PLT (Procedure Linkage Table) entries for function calls, whereas GCC behaves correctly and does not generate PLT entries.

This issue affects scenarios where direct GOT-based access is expected, and the presence of PLT entries may lead to unnecessary indirection and performance overhead.

Compile the following code with Clang 19 dev and -fno-plt

//  gcc 1.c -shared -fno-plt  -O0 -o libnoplt-clang.so -fPIC
//  clang 1.c -shared -fno-plt  -O0 -o libnoplt-gcc.so -fPIC
int bar(int a) {
  return 10;
}
int foo(int a) {
  return bar(a);
}

The Clang-compiled version generates PLT functions, while the GCC version does not.

// libnoplt-clang.so
Disassembly of section .plt:

0000000000000440 <.plt>:
 440:	a9bf7bf0 	stp	x16, x30, [sp, #-16]!
 444:	f00000f0 	adrp	x16, 1f000 <__FRAME_END__+0x1e934>
 448:	f947fe11 	ldr	x17, [x16, #4088]
 44c:	913fe210 	add	x16, x16, #0xff8
 450:	d61f0220 	br	x17
 454:	d503201f 	nop
 458:	d503201f 	nop
 45c:	d503201f 	nop

0000000000000470 <bar@plt>:
 470:	90000110 	adrp	x16, 20000 <__cxa_finalize@GLIBC_2.17>
 474:	f9400611 	ldr	x17, [x16, #8]
 478:	91002210 	add	x16, x16, #0x8
 47c:	d61f0220 	br	x17

0000000000000588 <foo>:
 588:	d10083ff 	sub	sp, sp, #0x20
 58c:	a9017bfd 	stp	x29, x30, [sp, #16]
 590:	910043fd 	add	x29, sp, #0x10
 594:	b81fc3a0 	stur	w0, [x29, #-4]
 598:	b85fc3a0 	ldur	w0, [x29, #-4]
 59c:	97ffffb5 	bl	470 <bar@plt>
 5a0:	a9417bfd 	ldp	x29, x30, [sp, #16]
 5a4:	910083ff 	add	sp, sp, #0x20
 5a8:	d65f03c0 	ret

// libnoplt-gcc.so
00000000000005c4 <bar>:
 5c4:	d10043ff 	sub	sp, sp, #0x10
 5c8:	b9000fe0 	str	w0, [sp, #12]
 5cc:	52800140 	mov	w0, #0xa                   	// #10
 5d0:	910043ff 	add	sp, sp, #0x10
 5d4:	d65f03c0 	ret

00000000000005d8 <foo>:
 5d8:	a9be7bfd 	stp	x29, x30, [sp, #-32]!
 5dc:	910003fd 	mov	x29, sp
 5e0:	b9001fe0 	str	w0, [sp, #28]
 5e4:	b9401fe0 	ldr	w0, [sp, #28]
 5e8:	f00000e1 	adrp	x1, 1f000 <__FRAME_END__+0x1e900>
 5ec:	f947e821 	ldr	x1, [x1, #4048]
 5f0:	d63f0020 	blr	x1
 5f4:	a8c27bfd 	ldp	x29, x30, [sp], #32
 5f8:	d65f03c0 	ret

Currently, LLVM has only been processed for the x86 and ARM + Mach-O architecture, but there are still problems with the aarch64 architecture.

relevant issue: Support fno-plt like gcc
relevant pr: Implement -fno-plt for SelectionDAG/GlobalISel

[chenzheng1030]

bar is a preemptable function, it is by intention that llvm does not use GOT for this kind of functions.

[MaskRay]

While the default visibility bar is preemptible if you link it with -shared in the default case, it is non-preemptible if you link it with -no-pie or -pie. (https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic) The compiler doesn't have sufficient information. A GOT-generating code sequence is costly on probably all RISC architectures.

I think Clang's behavior is ideal and don't think we should match GCC.