[Bug ld/16787] New: LD gives wrong error messages
https://sourceware.org/bugzilla/show_bug.cgi?id=16787
Bug ID: 16787
Summary: LD gives wrong error messages
Product: binutils
Version: 2.24
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: ma.jiang at zte dot com.cn
Created attachment 7512
--> https://sourceware.org/bugzilla/attachment.cgi?id=7512&action=edit
for bug reproduce
unzip the attached file, put these files into the directory of a cross-compiler
for arm.Run the bug.sh. Linker will throw out error messages like :
t1234.o: In function `t1':
/home/majiang/toolchain_compile/ToolsChain/gcc4.5.2_glibc2.13.0/install/arm_eabi_gcc4.5.2_glibc2.13.0/bin/t1.c:2:
warning: Using 'getgrgid' in statically linked applications requires at runtime
the shared libraries from the glibc version used for linking
t1234.o: In function `tp_842':
/home/majiang/toolchain_compile/ToolsChain/gcc4.5.2_glibc2.13.0/install/arm_eabi_gcc4.5.2_glibc2.13.0/bin/t4.c:12:
undefined reference to `udf'
collect2: ld returned 1 exit status
But, in fact the reference to 'udf' is in t3.c as you can see from the source
codes.The Gnu Linker gives out a totally wrong message here.
==
This problem has something to do with the bfd interface
_bfd_dwarf2_slurp_debug_info.This function uses a cached debug info which is
wrong in some circumstance. More specifically, _bfd_dwarf2_slurp_debug_info
load and parse the debug info sections when ld generated getgrgid warning.At
that time,output sections(especially their vma) are not determined. When ld
generated the udf error, output sections have their vma now while
_bfd_dwarf2_slurp_debug_info still use the cached debug info. Finally,the bug
jump out. The find_line function add the section->output_section->vma to the
reloc offset of udf, and the aranges of compilation units in cached debug info
do not change with it. At last, the find_line function find a wrong file/lineno
for the udf reference.
=
To fix this problem, ld need to clear the wrong cache when things have changed.
My solution is to call the function below right after the lang_process function
call lang_size_sections (NULL, ! RELAXATION_ENABLED).
static void reset_all_debuginfo(void)
{
bfd * input_bfd;
for (input_bfd = link_info.input_bfds;
input_bfd != NULL;
input_bfd = input_bfd->link_next)
{
struct elf_obj_tdata *tdata = ((input_bfd) -> tdata.elf_obj_data);
if (bfd_get_format (input_bfd) == bfd_object && tdata != NULL)
{
_bfd_dwarf2_cleanup_debug_info(input_bfd,
&tdata->dwarf2_find_line_info);
tdata->dwarf2_find_line_info = NULL;
}
}
}
--
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/16788] New: Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 Bug ID: 16788 Summary: Gold produces unbootable Linux kernel Product: binutils Version: 2.25 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ian at airs dot com Reporter: markus at trippelsdorf dot de CC: ccoutant at google dot com Building the Linux kernel (current git) with gold causes the kernel to hang very early during boot. It is the following command that makes the difference: ld -m elf_x86_64 --build-id -o vmlinux -T /usr/src/linux/arch/x86/kernel/vmlinux.lds arch/x86/kernel/head_64.o arch/x86/kernel/head64.o arch/x86/kernel/head.o init/built-in.o --start-group usr/built-in.o arch/x86/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/x86/lib/lib.a lib/built-in.o arch/x86/lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o arch/x86/pci/built-in.o arch/x86/power/built-in.o arch/x86/video/built-in.o net/built-in.o --end-group .tmp_kallsyms2.o With gold I get: There are 31 section headers, starting at offset 0xb3e2d0: Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS8100 001000 56526f 00 AX 0 0 4096 [ 2] .notesNOTE81565270 566270 40 00 A 0 0 4 [ 3] __ex_tablePROGBITS815652b0 5662b0 000ee0 00 A 0 0 8 [ 4] .rodata PROGBITS8160 601000 1c4448 00 A 0 0 64 [ 5] __bug_table PROGBITS817c4448 7c5448 005580 00 A 0 0 1 [ 6] .pci_fixupPROGBITS817c99c8 7ca9c8 002988 00 A 0 0 8 [ 7] .builtin_fw PROGBITS817cc350 7cd350 0002b8 00 A 0 0 8 [ 8] __param PROGBITS817cc608 7cd608 002180 00 A 0 0 8 [ 9] __modver PROGBITS817ce788 7cf788 000878 00 A 0 0 8 [10] .data PROGBITS8180 7d 06f000 00 WA 0 0 4096 [11] __tracepoint_str PROGBITS8186f000 83f000 10 00 WA 0 0 8 [12] .vvar PROGBITS8187 84 f0 00 WA 0 0 16 [13] .data..percpu PROGBITS 841000 012540 00 WA 0 0 4096 [14] .init.textPROGBITS81884000 854000 02b7dc 00 AX 0 0 16 [15] .init.dataPROGBITS818b 88 06e448 00 WA 0 0 4096 [16] .x86_cpu_dev.init PROGBITS8191e448 8ee448 08 00 A 0 0 8 [17] .altinstructions PROGBITS8191e450 8ee450 000f9c 00 A 0 0 1 [18] .altinstr_replacement PROGBITS8191f3ec 8ef3ec 00055a 00 AX 0 0 1 [19] .iommu_table PROGBITS8191f948 8ef948 50 00 A 0 0 8 [20] .apicdrivers PROGBITS8191f998 8ef998 10 00 WA 0 0 8 [21] .exit.textPROGBITS8191f9a8 8ef9a8 00157e 00 AX 0 0 1 [22] .smp_locksPROGBITS81921000 8f1000 005000 00 A 0 0 4 [23] .data_nosave PROGBITS81926000 8f6000 00 00 A 0 0 0 [24] .bss NOBITS 81926000 8f6000 096000 00 WA 0 0 4096 [25] .brk NOBITS 819bc000 98c000 026000 00 WA 0 0 1 [26] .comment PROGBITS 9b2000 2a 01 MS 0 0 1 [27] .debug_frame PROGBITS 9b2030 001b90 00 0 0 8 [28] .symtab SYMTAB 9b3bc0 0dfef0 18 29 23572 8 [29] .strtab STRTAB a93ab0 0aa6e6 00 0 0 1 [30] .shstrtab STRTAB b3e196 00013a 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), l (large) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Elf file type is EXEC (Executable file) Entry point 0x100 There are 5 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x8100 0x0100 0x7cf000 0x7cf000 R E 0x20 LOAD 0x7d 0x8180 0x0180 0x0700f0 0x0700f0 RW 0x20 LOAD 0x841000 0x 0x01871000 0x012540 0x012540 RW 0x20 LOAD 0x854000 0x81884000 0x01884000 0x15e000 0x15e000 RWE 0x20 NOTE 0x5662
[Bug gold/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #1 from Markus Trippelsdorf --- Created attachment 7514 --> https://sourceware.org/bugzilla/attachment.cgi?id=7514&action=edit kernel linker script -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #2 from Markus Trippelsdorf --- > So the .text section is at the wrong offset with gold (0x001000 vs. 0x20). No. The text offset is not the reason. Let me dig deeper. -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 Markus Trippelsdorf changed: What|Removed |Added CC||luto at mit dot edu --- Comment #3 from Markus Trippelsdorf --- CCing Andy. Maybe he knows what is going on. The first lines of the disassembly diff look like: --- good2014-04-01 16:42:13.680345325 +0200 +++ bad 2014-04-01 16:41:52.877489192 +0200 @@ -107,32 +107,25 @@ 810001a4 : 810001a4: eb fe jmp810001a4 -810001a6: 90 nop -810001a7: 90 nop + ... 810001a8 <_stext>: -810001a8: 90 nop -810001a9: 90 nop +810001a8: 00 00 add%al,(%rax) 810001aa: 90 nop 810001ab: 90 nop -810001ac: 90 nop -810001ad: 90 nop +810001ac: 00 00 add%al,(%rax) 810001ae: 90 nop 810001af: 90 nop -810001b0: 90 nop -810001b1: 90 nop +810001b0: 00 00 add%al,(%rax) 810001b2: 90 nop 810001b3: 90 nop -810001b4: 90 nop -810001b5: 90 nop +810001b4: 00 00 add%al,(%rax) 810001b6: 90 nop 810001b7: 90 nop -810001b8: 90 nop -810001b9: 90 nop +810001b8: 00 00 add%al,(%rax) 810001ba: 90 nop 810001bb: 90 nop -810001bc: 90 nop -810001bd: 90 nop +810001bc: 00 00 add%al,(%rax) 810001be: 90 nop 810001bf: 90 nop @@ -165,7 +158,7 @@ 81000218: c3 retq 81000219: 89 da mov%ebx,%edx 8100021b: 48 89 eemov%rbp,%rsi -8100021e: 48 c7 c7 10 e7 75 81mov$0x8175e710,%rdi +8100021e: 48 c7 c7 c8 cf 78 81mov$0x8178cfc8,%rdi 81000225: 31 c0 xor%eax,%eax 81000227: e8 75 b2 55 00 callq 8155b4a1 8100022c: eb e6 jmp81000214 @@ -226,19 +219,19 @@ 810002c3: b9 09 00 00 00 mov$0x9,%ecx 810002c8: 53 push %rbx 810002c9: 48 89 fbmov%rdi,%rbx -810002cc: 48 c7 c7 3a e6 75 81mov$0x8175e63a,%rdi +810002cc: 48 c7 c7 6c e6 75 81mov$0x8175e66c,%rdi 810002d3: 48 89 demov%rbx,%rsi 810002d6: 48 83 ec 30 sub$0x30,%rsp 810002da: f3 a6 repz cmpsb %es:(%rdi),%ds:(%rsi) 810002dc: 0f 84 86 00 00 00 je 81000368 810002e2: b9 05 00 00 00 mov$0x5,%ecx -810002e7: 48 c7 c7 53 e6 75 81mov$0x8175e653,%rdi +810002e7: 48 c7 c7 85 e6 75 81mov$0x8175e685,%rdi 810002ee: 48 89 demov%rbx,%rsi 810002f1: f3 a6 repz cmpsb %es:(%rdi),%ds:(%rsi) 810002f3: 0f 85 ff 00 00 00 jne810003f8 810002f9: 48 8d 6b 05 lea0x5(%rbx),%rbp 810002fd: b9 04 00 00 00 mov$0x4,%ecx -81000302: 48 c7 c7 88 1d 77 81mov$0x81771d88,%rdi +81000302: 48 c7 c7 91 e6 75 81mov$0x8175e691,%rdi 81000309: 48 89 eemov%rbp,%rsi 8100030c: b8 ff 00 00 00 mov$0xff,%eax 81000311: f3 a6 repz cmpsb %es:(%rdi),%ds:(%rsi) @@ -253,7 +246,7 @@ 81000325: c3 retq 81000326: 66 90 xchg %ax,%ax 81000328: b9 04 00 00 00 mov$0x4,%ecx -8100032d: 48 c7 c7 0a 20 7b 81mov$0x817b200a,%rdi +8100032d: 48 c7 c7 95 e6 75 81mov$0x8175e695,%rdi 81000334:
[Bug ld/16790] New: [cygwin|mingw] ld -v creates a.exe
https://sourceware.org/bugzilla/show_bug.cgi?id=16790 Bug ID: 16790 Summary: [cygwin|mingw] ld -v creates a.exe Product: binutils Version: 2.25 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: nickc at redhat dot com Reporter: yselkowitz at cygwin dot com Nick, A possibly unforeseen side-effect has resulted from the addition of default-manifest support for PE targets. Usually, a simple '[$target-]ld -v' only prints the version, and '[$target-]ld --verbose' without any other arguments prints the linker script but does not create a file. However, with the new Cygwin binutils (20140326 snapshot), an a.exe file is created in both cases. I presume this was not intentional. Could the previous behaviour be restored (IOW do not include default-manifest.o if there is nothing else to link)? -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #4 from Andy Lutomirski --- It looks like gold has a different interpretation of what ":text = 0x9090" means than the bfd linker. Can you try changing that to ":text = 0x90909090" in arch/x86/kernel/vmlinux.lds.S? This is definitely a gold bug, or at least a difference between gold and bfd, but I doubt it's causing your problem, since using :text = 0x9090 on bfd still produces a working kernel for me. That being said, I just generated a working kernel with GNU gold (version 2.23.2) 1.11. Can you post a kernel image or a config or something? -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #5 from Markus Trippelsdorf --- (In reply to Andy Lutomirski from comment #4) > It looks like gold has a different interpretation of what ":text = 0x9090" > means than the bfd linker. Can you try changing that to ":text = > 0x90909090" in arch/x86/kernel/vmlinux.lds.S? It still hangs when I change it. > This is definitely a gold bug, or at least a difference between gold and > bfd, but I doubt it's causing your problem, since using :text = 0x9090 > on bfd still produces a working kernel for me. > > That being said, I just generated a working kernel with GNU gold (version > 2.23.2) 1.11. Can you post a kernel image or a config or something? This is a bizarre issue, because when I edit the kernel, by deleting e.g. a single printk, the kernel boots fine. The same thing happens when I switch to a different compiler. So it appears that some strange coincidence must happen for this bug to trigger. I have uploaded the hanging kernel image to: http://trippelsdorf.de/bzImage (I use: qemu-system-x86_64 -s -enable-kvm -net nic,vlan=0,model=virtio -net user -fsdev local,security_model=none,id=root,path=/ -device virtio-9p-pci,id=root,fsdev=root,mount_tag=/dev/root -m 512 -smp 1 -kernel /usr/src/linux/arch/x86/boot/bzImage -nographic -append "init=/bin/zsh root=/dev/root console=ttyS0 kgdboc=ttyS0 rootflags=rw,trans=virtio rootfstype=9p ip=dhcp earlyprintk=ttyS0" for testing) -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #7 from Andy Lutomirski --- (In reply to Cary Coutant from comment #6) > (In reply to Andy Lutomirski from comment #4) > > It looks like gold has a different interpretation of what ":text = 0x9090" > > means than the bfd linker. Can you try changing that to ":text = > > 0x90909090" in arch/x86/kernel/vmlinux.lds.S? > > > > This is definitely a gold bug, or at least a difference between gold and > > bfd, but I doubt it's causing your problem, since using :text = 0x9090 > > on bfd still produces a working kernel for me. > > > > That being said, I just generated a working kernel with GNU gold (version > > 2.23.2) 1.11. Can you post a kernel image or a config or something? > > Yes, in gold, the fill value is always 4 bytes in length. There's a FIXME in > the code to support arbitrary lengths, but that seems unlikely to be the > problem here. Fixing it for one and two bytes would be trivial :) -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #9 from Cary Coutant --- > > Yes, in gold, the fill value is always 4 bytes in length. There's a FIXME in > > the code to support arbitrary lengths, but that seems unlikely to be the > > problem here. > > Fixing it for one and two bytes would be trivial :) How does GNU ld determine the size? In gold, we treat the fill value as an arbitrary expression, so by the time we get the actual value to use, we have no idea how large the given value was. If it's based on the size of the constant given (e.g., 0x9090 is two bytes and 0x9090 is four bytes), it's not trivial. If it's simply based on the magnitude (e.g., 0x9090 and 0x9090 are both two bytes), then yes, it probably is trivial -- but then how would you express a fill pattern like 0x9090 where you really want 00 00 90 90 00 00 90 90 ...? -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #6 from Cary Coutant --- (In reply to Andy Lutomirski from comment #4) > It looks like gold has a different interpretation of what ":text = 0x9090" > means than the bfd linker. Can you try changing that to ":text = > 0x90909090" in arch/x86/kernel/vmlinux.lds.S? > > This is definitely a gold bug, or at least a difference between gold and > bfd, but I doubt it's causing your problem, since using :text = 0x9090 > on bfd still produces a working kernel for me. > > That being said, I just generated a working kernel with GNU gold (version > 2.23.2) 1.11. Can you post a kernel image or a config or something? Yes, in gold, the fill value is always 4 bytes in length. There's a FIXME in the code to support arbitrary lengths, but that seems unlikely to be the problem here. -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #8 from Cary Coutant --- > -8100021e: 48 c7 c7 10 e7 75 81mov > $0x8175e710,%rdi > +8100021e: 48 c7 c7 c8 cf 78 81mov > $0x8178cfc8,%rdi > -810002cc: 48 c7 c7 3a e6 75 81mov > $0x8175e63a,%rdi > +810002cc: 48 c7 c7 6c e6 75 81mov > $0x8175e66c,%rdi Differences like these could be the problem, but it's more likely that these just reflect slight differences in layout between the two linkers (the operand addresses are in .rodata). I'm not sure why gold is bumping the text segment up to offset 0x2 in the file, though; it may have something to do with the way we handle ALIGN in the script. Theoretically, the virtual addresses are the same in both files, so the results should be equivalent, but it's possible that the kernel really depends on it starting at 0x1000. -cary -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #10 from Markus Trippelsdorf --- Not sure if this is relevant, but building gold with "-fsanitize=undefined" shows: markus@x4 linux % /var/tmp/binutils-gdb/gold/ld-new -m elf_x86_64 --build-id -o vmlinux -T /usr/src/linux/arch/x86/kernel/vmlinux.lds arch/x86/kernel/head_64.o arch/x86/kerne l/head64.o arch/x86/kernel/head.o init/built-in.o --start-group usr/built-in.o arch/x86/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/x86/lib/lib.a lib/built-in.o arch/x86/lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o arch/x86/pci/built-in.o arch/x86/power/built-in.o arch/x86/video/built-in.o net/built-in.o --end-group .tmp_kallsyms2.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4/bits/stl_tree.h:741:25: runtime error: downcast of address 0x7fff5e2a2850 with insufficient space for an object of type '_Rb_tree_node, gold::Output_segment *> >' 0x7fff5e2a2850: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 10 2c f4 02 00 00 00 00 50 2c f4 02 00 00 00 00 90 2c f4 02 ^ -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #11 from Markus Trippelsdorf --- Backtrace with -fsanitize-undefined-trap-on-error: Program received signal SIGILL, Illegal instruction. gold::Script_sections::attach_sections_using_phdrs_clause (this=, layout=) at script-sections.cc:4155 4155 if (r == name_to_segment.end()) (gdb) bt #0 gold::Script_sections::attach_sections_using_phdrs_clause (this=, layout=) at script-sections.cc:4155 #1 0x00634326 in create_segments_from_phdrs_clause (this=0x7fffe048, layout=0x7fff7c50, dot_alignment=) at script-sections.cc:4069 #2 gold::Script_sections::create_segments (this=0x7fffe048, layout=0x7fff7c50, dot_alignment=2097152) at script-sections.cc:3774 #3 0x00634255 in gold::Script_sections::set_section_addresses (this=0x7fffe048, symtab=, layout=0x7fff7c50) at script-sections.cc:3603 #4 0x0057eafd in set_section_addresses_from_script (this=0x7fff7c50, symtab=0x7fff80b8) at layout.cc:3846 #5 gold::Layout::relaxation_loop_body (this=0x7fff7c50, pass=0, target=0x7a7c50, symtab=0x7fff80b8, pload_seg=0x7fff7918, phdr_seg=0x0, segment_headers= 0x1045010, file_header=0x890dd0, pshndx=) at layout.cc:2448 #6 0x0056e581 in gold::Layout::finalize (this=0x7fff7c50, input_objects=0x7fff84c8, symtab=0x7fff80b8, target=0x7a7c50, task=0xaf3160) at layout.cc:2735 #7 0x0056dffb in gold::Layout_task_runner::run (this=0xaf31a0, workqueue=0x7fff8530, task=0xaf3160) at layout.cc:375 #8 0x0066a820 in gold::Workqueue::find_and_run_task (this=0x7fff8530, thread_number=0) at workqueue.cc:319 #9 0x0066af0a in gold::Workqueue::process (this=0x7fff8530, thread_number=0) at workqueue.cc:495 #10 0x00405095 in main (argc=35, argv=0x7fffe238) at main.cc:252 -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #12 from Markus Trippelsdorf --- Hmm, I think the -fsanitize issue is a red herring. Here is the full "objdump -d vmlinux" diff: trippelsdorf.de/diff.bz2 -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #13 from Andy Lutomirski --- (In reply to Cary Coutant from comment #9) > > > Yes, in gold, the fill value is always 4 bytes in length. There's a FIXME > > > in > > > the code to support arbitrary lengths, but that seems unlikely to be the > > > problem here. > > > > Fixing it for one and two bytes would be trivial :) > > How does GNU ld determine the size? In gold, we treat the fill value as an > arbitrary expression, so by the time we get the actual value to use, we have > no idea how large the given value was. If it's based on the size of the > constant given (e.g., 0x9090 is two bytes and 0x9090 is four bytes), > it's not trivial. If it's simply based on the magnitude (e.g., 0x9090 and > 0x9090 are both two bytes), then yes, it probably is trivial -- but then > how would you express a fill pattern like 0x9090 where you really want > 00 00 90 90 00 00 90 90 ...? Fair enough. I assume that GNU ld treats it as bytes instead of as an expression, but I've never checked. -- 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/16794] New: gold doesn't include the "implicit addend" when processing REL relocations to mergable sections
https://sourceware.org/bugzilla/show_bug.cgi?id=16794 Bug ID: 16794 Summary: gold doesn't include the "implicit addend" when processing REL relocations to mergable sections Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ian at airs dot com Reporter: rafael.espindola at gmail dot com CC: ccoutant at google dot com Created attachment 7516 --> https://sourceware.org/bugzilla/attachment.cgi?id=7516&action=edit testcase The attached testcase has both 32 and 64 bit versions of a test. The file test.o contains relocations to a mergeable section. In the 32 bit case it has: 0012 0509 R_386_GOTOFF .rodata.str1.1 001c 0509 R_386_GOTOFF .rodata.str1.1 The "implicit addend" are in the two lea instructions: objdump -d test.o 10:8d 83 07 00 00 00lea0x7(%ebx),%eax 16:89 44 24 04 mov%eax,0x4(%esp) 1a:8d 83 00 00 00 00lea0x0(%ebx),%eax On the gold produced output, the distance between the two is still 7 (0x11ac- 0x11a5) 80484e0: 8d 83 5b ee ff ff lea-0x11a5(%ebx),%eax 80484e6: 89 44 24 04 mov%eax,0x4(%esp) 80484ea: 8d 83 54 ee ff ff lea-0x11ac(%ebx),%eax The the actual section has been modified to merge the strings, so that is no longer valid. Using bfd ld, the offset is updated: 8048460: 8d 83 4d ee ff ff lea-0x11b3(%ebx),%eax 8048466: 89 44 24 04 mov%eax,0x4(%esp) 804846a: 8d 83 4c ee ff ff lea-0x11b4(%ebx),%ea Everything works on 64 bits. I assume that is because it uses RELA relocations. In 64 bits the test.o file has 0003 00050002 R_X86_64_PC32 .rodata.str1.1 + 0 000a 00050002 R_X86_64_PC32 .rodata.str1.1 + 7 0:48 8d 3d 00 00 00 00 lea0x0(%rip),%rdi 7:48 8d 35 00 00 00 00 lea0x0(%rip),%rsi and the final binary is update correctly 400530: 48 8d 3d ad 00 00 00lea0xad(%rip),%rdi 400537: 48 8d 35 a7 00 00 00lea0xa7(%rip),%rsi -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #14 from Andy Lutomirski --- Markus, can you see if arch/x86/boot/compressed/piggy.S is the same on a good and a bad kernel? It may also be worth comparing arch/x86/boot/compressed/vmlinux between kernels. (This is, confusingly, not the same thing as vmlinux in the root directory.) It's also probably worth trying to reproduce this with CONFIG_X86_VERBOSE_BOOTUP=y. -- 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
