https://sourceware.org/bugzilla/show_bug.cgi?id=34423
--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jan Beulich from comment #1)
> But, first of all, bar<N> would normally be defined in the same TU. Albeit
> perhaps this makes no difference here.
bar<N> can be external functions called via PLT.
> Second, in a .long (or other data) directive, how would you pick between
> PC32 and PLT32? Aiui it would need to be the compiler to request this, by
> using @plt. Otherwise we have no way to disambiguate.
>
> Which then runs foul of gas not permitting:
>
> .long bar0@plt - .L4
When bar0 is an external function, assembler accepts
".long bar0 - .L4". But linker generates R_X86_64_PC32
run-time relocation:
[hjl@gnu-tgl-3 pic-2]$ cat main.c
#include <stdio.h>
#include <stdint.h>
void
bar0 (void)
{
printf ("%s\n", __FUNCTION__);
}
void
bar1 (void)
{
printf ("%s\n", __FUNCTION__);
}
void
bar2 (void)
{
printf ("%s\n", __FUNCTION__);
}
void
bar3 (void)
{
printf ("%s\n", __FUNCTION__);
}
void
bar4 (void)
{
printf ("%s\n", __FUNCTION__);
}
extern int jump_table[];
int
main ()
{
int i;
void *p = jump_table;
for (i = 0; i < 5; i++)
printf ("%d: %p\n", i, p + jump_table[i]);
return 0;
}
[hjl@gnu-tgl-3 pic-2]$ cat j.S
.globl jump_table
.type jump_table, @object
.data
.p2align 2
jump_table:
.L4:
.long bar0-.L4
.long bar1-.L4
.long bar2-.L4
.long bar3-.L4
.long bar4-.L4
.size jump_table, .-jump_table
.section .note.GNU-stack,"",@progbits
[hjl@gnu-tgl-3 pic-2]$ make
gcc -B./ -O2 -c -o main.o main.c
as -O -o j.o j.S
ld -shared -o libj.so j.o
gcc -B./ -O2 -o x main.o libj.so -Wl,-R,.
./x
./x: Symbol `bar0' causes overflow in R_X86_64_PC32 relocation
./x: Symbol `bar1' causes overflow in R_X86_64_PC32 relocation
./x: Symbol `bar2' causes overflow in R_X86_64_PC32 relocation
./x: Symbol `bar3' causes overflow in R_X86_64_PC32 relocation
./x: Symbol `bar4' causes overflow in R_X86_64_PC32 relocation
0: 0xffffffffece21184
1: 0xffffffffece21194
2: 0xffffffffece211a4
3: 0xffffffffece211b4
4: 0xffffffffece211c4
[hjl@gnu-tgl-3 pic-2]$
Can we generate R_X86_64_PLT32, instead of R_X86_64_PC32,
against undefined function symbol?
--
You are receiving this mail because:
You are on the CC list for the bug.
