Bug 20833 - x32 kernel build error
Summary: x32 kernel build error
Status: UNCONFIRMED
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: 2.28
: P2 normal
Target Milestone: ---
Assignee: Cary Coutant
URL:
Keywords:
: 21230 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-11-17 10:11 UTC by Markus Trippelsdorf
Modified: 2019-02-17 18:35 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
testcase (11.95 KB, application/x-tar)
2016-11-17 10:11 UTC, Markus Trippelsdorf
Details
A patch (600 bytes, patch)
2016-11-17 19:46 UTC, H.J. Lu
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Trippelsdorf 2016-11-17 10:11:38 UTC
Created attachment 9642 [details]
testcase

A Gentoo user reported an error when using gold to build Linux kernel with x32 enabled:

markus@x4 testcase % gcc -fuse-ld=bfd -nostdlib -Wl,-m,elf32_x86_64 -Wl,-T,vdsox32.lds vclock_gettime-x32.o
markus@x4 testcase % gcc -fuse-ld=gold -nostdlib -Wl,-m,elf32_x86_64 -Wl,-T,vdsox32.lds vclock_gettime-x32.o
arch/x86/entry/vdso/vclock_gettime.c:246: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:240: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:241: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:230: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:231: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:213: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:212: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:170: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:214: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:216: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:192: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:191: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:170: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:193: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:195: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:148: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:178: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:179: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:148: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:178: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:179: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:275: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:192: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:191: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:170: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:193: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:195: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:281: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:282: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:148: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:178: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:179: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
arch/x86/entry/vdso/vclock_gettime.c:297: error: relocation overflow: reference to 'vvar_vsyscall_gtod_data'
collect2: error: ld returned 1 exit status

gold 2.26.1. was fine.
Comment 1 H.J. Lu 2016-11-17 19:46:51 UTC
Created attachment 9644 [details]
A patch

Try this.
Comment 2 Markus Trippelsdorf 2016-11-17 19:54:51 UTC
(In reply to H.J. Lu from comment #1)
> Created attachment 9644 [details]
> A patch
> 
> Try this.

Works fine. Thank you.
Comment 3 H.J. Lu 2016-11-17 21:57:22 UTC
Technically, gold is correct to complain relocation overflow.
But vvar_vsyscall_gtod_data is in vvar page which is placed before
vdso page:

7fffe89d8000-7fffe89da000 r--p 00000000 00:00 0                          [vvar]
7fffe89da000-7fffe89dc000 r-xp 00000000 00:00 0                          [vdso]

There is no good way to express it. ld happens to store the absolute
value of 0xffffe080 as 0xffffffffffffe080.
Comment 4 H.J. Lu 2016-11-18 18:38:04 UTC
Gold can implement -z noreloc-overflow to disable relocation overflow check
and -z noreloc-overflow should be used to build vdso.
Comment 5 Cary Coutant 2016-11-21 18:16:35 UTC
(In reply to H.J. Lu from comment #3)
> Technically, gold is correct to complain relocation overflow.
> But vvar_vsyscall_gtod_data is in vvar page which is placed before
> vdso page:
> 
> 7fffe89d8000-7fffe89da000 r--p 00000000 00:00 0                         
> [vvar]
> 7fffe89da000-7fffe89dc000 r-xp 00000000 00:00 0                         
> [vdso]
> 
> There is no good way to express it. ld happens to store the absolute
> value of 0xffffe080 as 0xffffffffffffe080.

HJ, is the patch you posted above intended for trunk? Or do you want instead a -z noreloc-overflow option?
Comment 6 H.J. Lu 2016-11-21 18:53:02 UTC
(In reply to Cary Coutant from comment #5)
> (In reply to H.J. Lu from comment #3)
> > Technically, gold is correct to complain relocation overflow.
> > But vvar_vsyscall_gtod_data is in vvar page which is placed before
> > vdso page:
> > 
> > 7fffe89d8000-7fffe89da000 r--p 00000000 00:00 0                         
> > [vvar]
> > 7fffe89da000-7fffe89dc000 r-xp 00000000 00:00 0                         
> > [vdso]
> > 
> > There is no good way to express it. ld happens to store the absolute
> > value of 0xffffe080 as 0xffffffffffffe080.
> 
> HJ, is the patch you posted above intended for trunk? Or do you want instead
> a -z noreloc-overflow option?

I prefer -z noreloc-overflow.  I haven't decided if ld should issue an error
for relocation overflow.
Comment 7 H.J. Lu 2016-11-21 22:03:18 UTC
X32 uses 32-bit pointers in 64-bit address space.  It can reach
the full 64-bit address space:

[hjl@gnu-6 far-3]$ cat x.c
#include <stdio.h>

extern int foo (long long);

int
main ()
{
  long long addr = 0xffffffffff600000LL;
  int x = foo (addr);
  printf ("0x%llx: %p\n", addr, x);
  return 0;
}
[hjl@gnu-6 far-3]$ cat foo.S
	.text
	.p2align 4,,15
	.globl	foo
	.type	foo, @function
foo:
.LFB0:
	.cfi_startproc
	movl	(%rdi), %eax
	ret
	.cfi_endproc
.LFE0:
	.size	foo, .-foo
	.section	.note.GNU-stack,"",@progbits
[hjl@gnu-6 far-3]$ gcc x.c foo.S -mx32
[hjl@gnu-6 far-3]$ ./a.out 
0xffffffffff600000: 0x60c0c748
[hjl@gnu-6 far-3]$ 

0xffffffffff600000 is mapped to vsyscall page, which is invisible to
normal x32 application.  In this sense, ld isn't wrong not to issue
an error to access below 0 for both LP64 and ILP32.
Comment 8 Markus Trippelsdorf 2017-03-07 16:32:38 UTC
*** Bug 21230 has been marked as a duplicate of this bug. ***
Comment 9 Sora Lee 2018-05-06 03:38:18 UTC
This still occurs with gold version 1.14 (binutils version 2.29.1).

I noticed https://sourceware.org/ml/binutils/2016-03/msg00202.html has been committed, however "-z noreloc-overflow" is still not recognised as a valid option.