
After porting BOLT to RISCV some of the relocations were broken on both AArch64 and X86. On AArch64 the example of broken relocations would be GOT, during handling them, we should replace the symbol to __BOLT_got_zero in order to address GOT entry, not the symbol that addresses this entry. This is done further in code, so it is too early to add rel here. On X86 it is a mistake to add relocations without addend. This is the exact problem that is raised on #97937. Due to different code generation I had to use gcc-generated yaml test, since with clang I wasn't able to reproduce problem. Added tests for both architectures and made the problematic condition riscV-specific.
26 lines
741 B
C
26 lines
741 B
C
// This test checks that referencing build_id through GOT table
|
|
// would result in GOT access after disassembly, not directly
|
|
// to build_id address.
|
|
|
|
// RUN: %clang %cflags -fuse-ld=lld -Wl,-T,%S/Inputs/build_id.ldscript -Wl,-q \
|
|
// RUN: -Wl,--no-relax -Wl,--build-id=sha1 %s -o %t.exe
|
|
// RUN: llvm-bolt -print-disasm --print-only=get_build_id %t.exe -o %t.bolt | \
|
|
// RUN: FileCheck %s
|
|
|
|
// CHECK: adrp [[REG:x[0-28]+]], __BOLT_got_zero
|
|
// CHECK: ldr x{{.*}}, [[[REG]], :lo12:__BOLT_got_zero{{.*}}]
|
|
|
|
struct build_id_note {
|
|
char pad[16];
|
|
char hash[20];
|
|
};
|
|
|
|
extern const struct build_id_note build_id_note;
|
|
|
|
__attribute__((noinline)) char get_build_id() { return build_id_note.hash[0]; }
|
|
|
|
int main() {
|
|
get_build_id();
|
|
return 0;
|
|
}
|