[Bug ld/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 --- Comment #10 from Nick Clifton --- Created attachment 9641 --> https://sourceware.org/bugzilla/attachment.cgi?id=9641&action=edit Compressed a,out that seg-faults -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 --- Comment #11 from Nick Clifton --- Hi Ma, (In reply to ma.jiang from comment #9) > Yes, the elf standard does not require " the program headers be contained > in a program segment". But, now that the generated elf have a PT_PHDR > segment, it must load the program header into memory, Hang on - I think that we need to check that we agree on the contents of the binary that we are talking about. I have uploaded a compressed a.bad file which is the executable I produced from your test.c source file, linked using the pad.ld linker script. This is the executable that I have been examining, and this executable does not have a PT_PHDR segment. Please could you compare this executable against the one that you are testing, and if they are different (which I suspect will be the case), please could you upload your version. It would also help if you could let me know how you produced that version, as obviously I must have done something different to you. > To tell the truth, it's not hard for me to find what is wrong(LOL). But > I'm a tool-chain maintainer in my company, and there are a lot of normal > users who will get totally confused by such problems. But hang on - why would a normal user be creating and using their own linker scripts ? This is something that should be completely hidden from the user, and something that they never have to worry about (or even know about). Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/20833] New: x32 kernel build error
https://sourceware.org/bugzilla/show_bug.cgi?id=20833 Bug ID: 20833 Summary: x32 kernel build error Product: binutils Version: 2.28 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: markus at trippelsdorf dot de CC: hjl.tools at gmail dot com, ian at airs dot com Target Milestone: --- Created attachment 9642 --> https://sourceware.org/bugzilla/attachment.cgi?id=9642&action=edit 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. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20815] throw errors for invalid load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=20815 --- Comment #12 from ma.jiang at zte dot com.cn --- Created attachment 9643 --> https://sourceware.org/bugzilla/attachment.cgi?id=9643&action=edit the invalid elf (In reply to Nick Clifton from comment #11) Hi Nick, I have checked your file. Yes, your elf is OK(as it does not have a PT_PHDR). I have found the way to create your elf on my server(gcc test.c -c; ld test.o pad.ld -o test). I create my elf using "gcc test.c pad.ld -o test".My elf do have a PT_PHDR. I have uploaded it,please check. > > > To tell the truth, it's not hard for me to find what is wrong(LOL). But > > I'm a tool-chain maintainer in my company, and there are a lot of normal > > users who will get totally confused by such problems. > > But hang on - why would a normal user be creating and using their own linker > scripts ? This is something that should be completely hidden from the user, > and something that they never have to worry about (or even know about). Trust me, there were so many such guys.This problem was reported by a expert in kernel(not in tool-chain...), when porting some hugepage tests to mips. Let us give them a hand, :) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/20834] New: ld.gold on armel uses small page size, decreasing portability
https://sourceware.org/bugzilla/show_bug.cgi?id=20834 Bug ID: 20834 Summary: ld.gold on armel uses small page size, decreasing portability Product: binutils Version: 2.28 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: doko at debian dot org CC: ian at airs dot com Target Milestone: --- [forwarded from https://bugs.debian.org/844467] Apparently some ARM based NAS devices, such as the WD My Cloud EX2, have the kernel using a page size of 32k or 64k. Binaries linked with ld.gold on armel use a page size of 4k. Trying to use those binaries with such a kernel fails: "ELF load command alignment not page-aligned" Using the regular ld on armel, a 64k (0x1) page size is used: # arm-linux-gnueabi-ld -o hello hello.o -lc # readelf -l hello | grep LOAD LOAD 0x00 0x0001 0x0001 0x001d2 0x001d2 R E 0x1 LOAD 0x0001d4 0x000201d4 0x000201d4 0x000b0 0x000b0 RW 0x1 Using ld.gold, a 4k (0x1000) page size is used: # arm-linux-gnueabi-ld.gold -o hello hello.o -lc # readelf -l hello | grep LOAD LOAD 0x00 0x8000 0x8000 0x001d2 0x001d2 R E 0x1000 LOAD 0x0001d2 0x91d2 0x91d2 0x000b2 0x000b2 RW 0x1000 ghc uses ld.gold to link haskell programs. Probably some other stuff links with ld.gold as well. This makes debian binaries, chroots, etc not as portable for use with such kernels as it could be. Workaround: Pass -z common-page-size=65536 -z max-page-size=65536 to ld.gold, however linking with -z common-page-size=65536 -z max-page-size=65536 fails: ld.gold.orig: internal error in do_write, at ../../gold/output.cc:464 It works using a 32kb page size. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/20834] ld.gold on armel uses small page size, decreasing portability
https://sourceware.org/bugzilla/show_bug.cgi?id=20834 Matthias Klose changed: What|Removed |Added Target||arm-linux-gnueabihf, ||arm-linux-gnueabi -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20828] [MIPS] produces invalid dynamic symbol table when --gc-sections is used since PR ld/13177 fix
https://sourceware.org/bugzilla/show_bug.cgi?id=20828 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-17 CC||amodra at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Alan Modra --- mips_elf_sort_hash_table_f takes no notice of local dynamic symbols, so that's why you have local and global symbols out of order. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20832] String merging elf32-i386 object files with elf64-x86-64 ld causes incorrect results
https://sourceware.org/bugzilla/show_bug.cgi?id=20832 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-11-17 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- This is a dup of PR 19013. Please try binutils 2.26 or newer. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/20833] x32 kernel build error
https://sourceware.org/bugzilla/show_bug.cgi?id=20833 --- Comment #1 from H.J. Lu --- Created attachment 9644 --> https://sourceware.org/bugzilla/attachment.cgi?id=9644&action=edit A patch Try this. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/20833] x32 kernel build error
https://sourceware.org/bugzilla/show_bug.cgi?id=20833 --- Comment #2 from Markus Trippelsdorf --- (In reply to H.J. Lu from comment #1) > Created attachment 9644 [details] > A patch > > Try this. Works fine. Thank you. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/20833] x32 kernel build error
https://sourceware.org/bugzilla/show_bug.cgi?id=20833 --- Comment #3 from H.J. Lu --- 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 00:00 0 [vvar] 7fffe89da000-7fffe89dc000 r-xp 00:00 0 [vdso] There is no good way to express it. ld happens to store the absolute value of 0xe080 as 0xe080. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20675] [metag] internal error cross-compiling static programs
https://sourceware.org/bugzilla/show_bug.cgi?id=20675 --- Comment #6 from wbx at openadk dot org --- Thanks Nick for looking into this. I think the patch is the best we can do for now. It seems more likely a gcc bug then a uClibc-ng problem. I can do the static toolchain test builds for all other uClibc-ng supported architectures without a problem. Unfortunately gcc support never made it into upstream for META, so I will just disable static testing for META on my site. Patch is fine for me and way more useful then an abort. Thanks Waldemar -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
