[Bug ld/22842] Handling of R_X86_64_PC32 in a PIE against a function in a shared library could be better
https://sourceware.org/bugzilla/show_bug.cgi?id=22842 --- Comment #9 from Rafael Ávila de Espíndola --- (In reply to Cary Coutant from comment #8) > I still believe that the linker is working as intended. If you want the > address of the PLT entry, use the PLT32 reloc. Why should -pie make a difference? All 3 linker produce a plt entry without -pie. This seems similar to the change to support copy relocations in pie executables. --- Comment #10 from H.J. Lu --- (In reply to Cary Coutant from comment #8) > I still believe that the linker is working as intended. If you want the > address of the PLT entry, use the PLT32 reloc. You do get the same value at run-time and linker can resolve it without dynamic relocation. -- 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/22844] Handling of R_X86_64_PC32 in a PIE against a function in a shared library could be better
https://sourceware.org/bugzilla/show_bug.cgi?id=22844 Rafael Ávila de Espíndola changed: What|Removed |Added CC||hjl.tools at gmail dot com -- 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/22844] New: Handling of R_X86_64_PC32 in a PIE against a function in a shared library could be better
https://sourceware.org/bugzilla/show_bug.cgi?id=22844
Bug ID: 22844
Summary: Handling of R_X86_64_PC32 in a PIE against a function
in a shared library could be better
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
Created attachment 10817
--> https://sourceware.org/bugzilla/attachment.cgi?id=10817&action=edit
testcase
The attached testcase has a shared library that defines a function foo with
default visibility. The function just prints its own address and argument:
void foo(void *bar) {
printf("%p %p\n", bar, foo);
}
There is also a position independent executable that uses a R_X86_64_PC32 to
find the address of foo and call it with that value.
The expected result is to see the same value printed twice.
If we try to use gold it errors out when linking the executable:
error: test.o: requires dynamic R_X86_64_PC32 reloc against 'foo' which may
overflow at runtime; recompile with -fPIC
With ld.bfd after 1031c264fd2364df1e12a35d0a8f7e82fb80 or ld.lld it works
since a canonical plt entry for foo is created in the main executable:
6: 11f0 0 FUNCGLOBAL DEFAULT UND foo
--
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/22842] Handling of R_X86_64_PC32 in a PIE against a function in a shared library could be better
https://sourceware.org/bugzilla/show_bug.cgi?id=22842 --- Comment #6 from Rafael Ávila de Espíndola --- (In reply to H.J. Lu from comment #5) > (In reply to Rafael Ávila de Espíndola from comment #4) > > (In reply to H.J. Lu from comment #3) > > > > > Should I close the bug and open a new one for gold or just reassign this > > one? > > Please leave it open for now until I check in my fix plus tests and > please open a new bug for gold. Note that at least for the testcase I created 1031c264fd2364df1e12a35d0a8f7e82fb80 is sufficient. That is, the test works *without* the patch on this bug. -- 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/22842] Handling of R_X86_64_PC32 in a PIE against a function in a shared library could be better
https://sourceware.org/bugzilla/show_bug.cgi?id=22842 --- Comment #4 from Rafael Ávila de Espíndola --- (In reply to H.J. Lu from comment #3) > (In reply to Rafael Ávila de Espíndola from comment #2) > > (In reply to H.J. Lu from comment #1) > > > Created attachment 10816 [details] > > > A patch > > > > > > Please try this. > > > > The runtime warning is gone, but I still get two different values for the > > address: > > > > $ ./run.sh > > 0x55d0082e2580 0x7f00497992d0 > > > > The symbol foo is also just a plain undefined: > > > > 0 FUNCGLOBAL DEFAULT UND foo > > Fixed on master branch by Awesome. I can confirm that it works now. Should I close the bug and open a new one for gold or just reassign this one? -- 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/22842] Handling of R_X86_64_PC32 in a PIE against a function in a shared library could be better
https://sourceware.org/bugzilla/show_bug.cgi?id=22842 --- Comment #2 from Rafael Ávila de Espíndola --- (In reply to H.J. Lu from comment #1) > Created attachment 10816 [details] > A patch > > Please try this. The runtime warning is gone, but I still get two different values for the address: $ ./run.sh 0x55d0082e2580 0x7f00497992d0 The symbol foo is also just a plain undefined: 0 FUNCGLOBAL DEFAULT UND foo -- 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 gas/22791] PLT32 should be used for 32-bit PC-relative branches
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #22 from Rafael Ávila de Espíndola --- (In reply to H.J. Lu from comment #21) > (In reply to Rafael Ávila de Espíndola from comment #20) > > Note that while the assembler change is a nice improvement, the original > > issue still exists. > > > > In the testcase that I attached before, the call to foo is now assembled to > > R_X86_64_PLT32, but > > > > .long foo - . > > > > Still produces a R_X86_64_PC32 as it has to. > > > > Since foo has default visibility, the linker could create a canonical plt > > entry to be the runtime address of foo. > > Please open a separate bug for this. https://sourceware.org/bugzilla/show_bug.cgi?id=22842 -- 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/22842] New: Handling of R_X86_64_PC32 in a PIE against a function in a shared library could be better
https://sourceware.org/bugzilla/show_bug.cgi?id=22842
Bug ID: 22842
Summary: Handling of R_X86_64_PC32 in a PIE against a function
in a shared library could be better
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rafael.espindola at gmail dot com
CC: ccoutant at gmail dot com, hjl.tools at gmail dot com
Target Milestone: ---
Created attachment 10815
--> https://sourceware.org/bugzilla/attachment.cgi?id=10815&action=edit
testcase
The attached testcase has a shared library that defines a function foo with
default visibility. The function just prints its own address and argument:
void foo(void *bar) {
printf("%p %p\n", bar, foo);
}
There is also a position independent executable that uses a R_X86_64_PC32 to
find the address of foo and call it with that value.
The expected result is to see the same value printed twice.
If we try to use gold it errors out when linking the executable:
error: test.o: requires dynamic R_X86_64_PC32 reloc against 'foo' which may
overflow at runtime; recompile with -fPIC
With ld.bfd it links but fails at runtime:
./test: Symbol `foo' causes overflow in R_X86_64_PC32 relocation
0x55ae794c62d0 0x7f0b794c62d0
With lld it works since lld create a canonical plt entry for foo in the main
executable:
6: 11f0 0 FUNCGLOBAL DEFAULT UND foo
--
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 gas/22791] PLT32 should be used for 32-bit PC-relative branches
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #20 from Rafael Ávila de Espíndola --- Note that while the assembler change is a nice improvement, the original issue still exists. In the testcase that I attached before, the call to foo is now assembled to R_X86_64_PLT32, but .long foo - . Still produces a R_X86_64_PC32 as it has to. Since foo has default visibility, the linker could create a canonical plt entry to be the runtime address of foo. -- 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 gas/22791] PLT32 should be used for 32-bit PC-relative branches
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #16 from Rafael Ávila de Espíndola --- > > If your argument is that you can always treat PC32 relocations on branches > > as if they were PLT32 relocations, why not just have the compiler emit PLT32 > > relocations in the first place? > > Yes, this patch does that: > > https://sourceware.org/ml/binutils/2018-02/msg00074.html If I understand it correctly, the idea is to generate a R_X86_64_PLT32 for "call foo" but a R_86_64_PC32 for ".long foo - .". If that is indeed what the patch is doing, I love it :-) -- 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/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #11 from Rafael Ávila de Espíndola --- (In reply to Cary Coutant from comment #10) > The "official" or "canonical" PLT entry is the one that serves as the > address of the function throughout the program. OK, so we were talking about the same plt entry. > If you make the function protected in your shared library, I think the PIC > sequence to get its address will always load the address of the function > itself, while the PC32 relocation in the main program will have no > alternative but to load the address of its own PLT entry. (Gnu ld will > refuse to build a shared library with a PC32 ref to a protected symbol, but > gold will build it.) That is what I would expect. Using a PLT entry in the main executable as the canonical PLT entry should work in the same cases where a copy relocation works: The use is in the main program and the definition has default visibility. -- 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/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791
--- Comment #9 from Rafael Ávila de Espíndola ---
(In reply to Cary Coutant from comment #8)
> (In reply to Rafael Ávila de Espíndola from comment #5)
> > (In reply to Cary Coutant from comment #4)
> > > This would be fine if we knew for a fact that the relocation is on a call
> > > instruction. The problem is that R_X86_64_PC32 isn't always a call
> > > instruction.
> >
> > It still works. The library will see the address of the got entry.
>
> Which won't necessarily be the "official" PLT entry. Function point
> comparison may break.
Not sure what you mean by "official". The testcase I uploaded computes address
of an external function foo with
movslq bar(%rip), %rax
leaqbar(%rip), %rdi
addq%rax, %rdi
...
.data
.p2align3
bar:
.long foo - .
and in a shared library foo is defined as
void foo(void *bar) {
printf("%p %p\n", bar, foo);
}
I always get the same value printed twice.
--
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/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #7 from Rafael Ávila de Espíndola --- (In reply to Rafael Ávila de Espíndola from comment #5) > (In reply to Cary Coutant from comment #4) > > This would be fine if we knew for a fact that the relocation is on a call > > instruction. The problem is that R_X86_64_PC32 isn't always a call > > instruction. > > It still works. The library will see the address of the got entry. > > I will upload a testcase. s/got/plt/ -- 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/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #6 from Rafael Ávila de Espíndola --- Created attachment 10787 --> https://sourceware.org/bugzilla/attachment.cgi?id=10787&action=edit testcase that prints the address of a function -- 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/22791] Don't error when a -pie executable uses a shared function without PIC/PIE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #5 from Rafael Ávila de Espíndola --- (In reply to Cary Coutant from comment #4) > This would be fine if we knew for a fact that the relocation is on a call > instruction. The problem is that R_X86_64_PC32 isn't always a call > instruction. It still works. The library will see the address of the got entry. I will upload a testcase. -- 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/22791] Don't error when a -pie executable uses a shared function without a got
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #3 from Rafael Ávila de Espíndola --- It seems to work. The attached hello world has Type: DYN (Shared object file) 6: 11e0 0 FUNCGLOBAL DEFAULT UND puts@GLIBC_2.2.5 and it works. -- 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/22791] Don't error when a -pie executable uses a shared function without a got
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 --- Comment #2 from Rafael Ávila de Espíndola --- Created attachment 10786 --> https://sourceware.org/bugzilla/attachment.cgi?id=10786&action=edit testcase -- 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/22791] New: Don't error when a -pie executable uses a shared function without a got
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 Bug ID: 22791 Summary: Don't error when a -pie executable uses a shared function without a got Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: rafael.espindola at gmail dot com CC: ian at airs dot com Target Milestone: --- The following testcase fails with gold $ cat test.s .globl _start _start: callq vcall $ cat test2.s .global vcall .type vcall,@function vcall: nop $ ld.gold test2.o -o test2.so -shared $ ld.gold test.o test2.so -o t -pie ld.gold: error: test.o: requires dynamic R_X86_64_PC32 reloc against 'vcall' which may overflow at runtime; recompile with -fPIC But there is no reason why trick of defining a symbol pointing to the plt entry would not work with a PIE. Starting with c5bb8910e80c6cd80c63541f86471c18375c8198 bfd uses TEXTREL, but that seems less desirable than creating a symbol pointing to the plt entry as is done in the non -pie case. -- 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/22791] Don't error when a -pie executable uses a shared function without a got
https://sourceware.org/bugzilla/show_bug.cgi?id=22791 Rafael Ávila de Espíndola changed: What|Removed |Added CC||ccoutant at gmail dot com -- 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 binutils/22587] Bogus readelf warning
https://sourceware.org/bugzilla/show_bug.cgi?id=22587 --- Comment #8 from Rafael Ávila de Espíndola --- Thanks! -- 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 binutils/22587] Bogus readelf warning
https://sourceware.org/bugzilla/show_bug.cgi?id=22587 --- Comment #5 from Rafael Ávila de Espíndola --- The patch avoids the warning. With it in place I think you can remove the special treatment for .rela.dyn too. -- 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 binutils/22587] Bogus readelf warning
https://sourceware.org/bugzilla/show_bug.cgi?id=22587 --- Comment #2 from Rafael Ávila de Espíndola --- I get an error compiling it: readelf.c:6210:14: error: ‘filedata’ undeclared (first use in this function); did you mean ‘file_ptr’? && (filedata->file_header.e_type == ET_EXEC But the intention seems correct. The condition you added should cover rela.dyn too, so you can probably delete that case. -- 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 binutils/22587] New: Bogus readelf warning
https://sourceware.org/bugzilla/show_bug.cgi?id=22587 Bug ID: 22587 Summary: Bogus readelf warning Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: rafael.espindola at gmail dot com Target Milestone: --- Relocations in non relocatable ELF files use virtual addresses, not section offsets. Given that, lld currently produces .rela.plt sections with a sh_info of 0. When processing such a file readelf prints readelf: Warning: [ 5]: Info field (0) should index a relocatable section. readelf special cases rela.dyn as the only section that is allowed to have a sh_info of 0. It should probably allow it on any relocation section in ET_EXEC and ET_DYN files. -- 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/22268] ld.gold accepts "foo = ~0xFF" in linker script while ld.bfd - not.
https://sourceware.org/bugzilla/show_bug.cgi?id=22268 Rafael Ávila de Espíndola changed: What|Removed |Added CC||rafael.espindola at gmail dot com -- 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/22267] ld.bfd does not accept "foo = ~0xFF" in linker script but accepts "foo = ~ 0xFF"
https://sourceware.org/bugzilla/show_bug.cgi?id=22267 Rafael Ávila de Espíndola changed: What|Removed |Added CC||rafael.espindola at gmail dot com -- 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/21493] New: gold -r corrupts comdats
https://sourceware.org/bugzilla/show_bug.cgi?id=21493 Bug ID: 21493 Summary: gold -r corrupts comdats Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: rafael.espindola at gmail dot com CC: ian at airs dot com Target Milestone: --- Given just -- .globl _start _start: callq foo .section.text.bar,"axG",@progbits,abc,comdat .section.text.foo,"axG",@progbits,xyz,comdat .global foo foo: mov $60, %rax mov $0, %rdi syscall -- the produced .o file has [ 1] .groupGROUP 40 08 04 10 6 4 [ 2] .groupGROUP 48 08 04 10 7 4 6: 0 NOTYPE LOCAL DEFAULT1 abc 7: 0 NOTYPE LOCAL DEFAULT2 xyz I.E, the sh_info points to the symbols where the group names are to be found. If we pass it to "gold -r", the output has [ 1] abc GROUP 40 08 04 9 1 4 [ 2] xyz GROUP 48 08 04 9 2 4 1: 0 SECTION LOCAL DEFAULT1 2: 0 SECTION LOCAL DEFAULT2 I.E., the sh_points to the section symbols. -- 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 gas/21287] New: Inconsistent section type for .init_array and .init_array.42
https://sourceware.org/bugzilla/show_bug.cgi?id=21287
Bug ID: 21287
Summary: Inconsistent section type for .init_array and
.init_array.42
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: rafael.espindola at gmail dot com
Target Milestone: ---
Given
.section.init_array.00999,"aw"
.section.init_array,"aw"
gas produces
[ 6] .init_array.00999 PROGBITS 58 08 00 WA
0 0 8
[ 8] .init_array INIT_ARRAY 60 08 00 WA
0 0 8
They should probably both be INIT_ARRAY. This shows up from C since given
struct X {
X();
};
X x __attribute__((init_priority(999)));
X y;
gcc produces the above assembly.
--
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 gas/21167] gas v2.28.51 does not include .rel[a] sections to groups
https://sourceware.org/bugzilla/show_bug.cgi?id=21167 Rafael Ávila de Espíndola changed: What|Removed |Added CC||rafael.espindola at gmail dot com -- 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] gold doesn't include the "implicit addend" when processing REL relocations to mergable sections
https://sourceware.org/bugzilla/show_bug.cgi?id=16794 --- Comment #2 from Rafael Ávila de Espíndola --- (In reply to Yin Ma from comment #1) > This patch made all DWARF DW_AT_name generation are wrong for ARM. Please > take a look again. I would like to know how LLVM need to work with gold > linker. Is this patch still needed? Sorry, I don' this patch was ever committed. You man that this bug causes problems? > The detail is here > https://llvm.org/bugs/show_bug.cgi?id=27985 -- 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/19823] gold produces copy reloc of protected symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=19823 --- Comment #6 from Rafael Ávila de Espíndola --- > Or, perhaps (I need to check...), gold might be incorrectly allowing > the COPY relocation to a protected symbol, failing to consider that > the bindings within the shared object will be static. (I thought that > came up a while ago, and got fixed, but maybe it was just something > similar.) If that's the case, you can either edit the title of this PR > or close this and file a separate one. Is the testcase in comment 3 what you had in mind? -- 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/19823] gold produces copy reloc of protected symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=19823 --- Comment #5 from Rafael Ávila de Espíndola --- (In reply to H.J. Lu from comment #4) > (In reply to Cary Coutant from comment #1) > > > > Or, perhaps (I need to check...), gold might be incorrectly allowing > > the COPY relocation to a protected symbol, failing to consider that > > the bindings within the shared object will be static. (I thought that > > came up a while ago, and got fixed, but maybe it was just something > > similar.) If that's the case, you can either edit the title of this PR > > or close this and file a separate one. > > It is done on purpose: > > https://sourceware.org/ml/binutils/2014-05/msg00059.html > https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00257.html I don't think this is related. The testcase is not pie. Gold already produced a copy relocation before a82bef932ec11cc16f205427f8a056c3c0ea517d. -- 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/19823] gold produces copy reloc of protected symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=19823 Rafael Ávila de Espíndola changed: What|Removed |Added Summary|gold doesn't consider copy |gold produces copy reloc of |reloc of protected symbols |protected symbols --- Comment #3 from Rafael Ávila de Espíndola --- $ cat test.s .global _start _start: .long foo $ cat lib.s .data .global foo .protected foo .type foo, @object .size foo, 4 foo: .long 0 $ gcc -c lib.s test.s $ ld.gold lib.o -shared -o lib.so $ ld.gold test.o lib.so -o t $ readelf -r t Relocation section '.rela.dyn' at offset 0x230 contains 1 entries: Offset Info Type Sym. ValueSym. Name + Addend 00401350 00010005 R_X86_64_COPY 00401350 foo + 0 [espindola@localhost llvm]$ readelf -sW lib.so | grep foo 1: 1290 4 OBJECT GLOBAL PROTECTED6 foo 2: 1290 4 OBJECT GLOBAL PROTECTED6 foo -- 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/19823] New: gold doesn't consider copy reloc of protected symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=19823 Bug ID: 19823 Summary: gold doesn't consider copy reloc of protected symbols Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: rafael.espindola at gmail dot com CC: ian at airs dot com Target Milestone: --- Given local: .global internal .internal internal internal: .global hidden .hidden hidden hidden: .global protected .protected protected protected .global default default: .quad local .quad internal .quad hidden .quad protected .quad default and linking with ld test.o -o test.so -shared gold and bfd agree on every relocation, except for protected where bfd produces 0268 00010001 R_X86_64_64 0250 protected + 0 and gold produces 02a0 0008 R_X86_64_RELATIVE288 The issue is that protected symbols cat still show up in copy relocations and in undefined plt entries. -- 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/19796] dynamic relocation missing simbol
https://sourceware.org/bugzilla/show_bug.cgi?id=19796 Rafael Ávila de Espíndola changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Rafael Ávila de Espíndola --- (In reply to Rafael Ávila de Espíndola from comment #2) > How does the dynamic handle this? > > A R_X86_64_TPOFF64 with no symbol is just the start of the thread block of > the dso it is in? Answering my own question by looking at musl: tls_val = def.sym ? def.sym->st_value : 0; So ld.bfd is just producing a more optimized version of what gold is producing. Sorry for the noise. -- 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/19796] dynamic relocation missing simbol
https://sourceware.org/bugzilla/show_bug.cgi?id=19796 --- Comment #2 from Rafael Ávila de Espíndola --- How does the dynamic handle this? A R_X86_64_TPOFF64 with no symbol is just the start of the thread block of the dso it is in? -- 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/19796] New: dynamic relocation missing simbol
https://sourceware.org/bugzilla/show_bug.cgi?id=19796
Bug ID: 19796
Summary: dynamic relocation missing simbol
Product: binutils
Version: 2.27 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rafael.espindola at gmail dot com
Target Milestone: ---
Given
--
bar:
movq%fs:0, %rax
addqfoo@GOTTPOFF(%rip), %rax
retq
.section.tbss,"awT",@nobits
foo:
.long 0
running ld.bfd test.o -o test.so -shared
will produce a file with a relocation that points to no symbol:
Offset Info Type Sym. ValueSym. Name +
Addend
002002e8 0012 R_X86_64_TPOFF64 0
with gold you get the expected result:
Offset Info Type Sym. ValueSym. Name +
Addend
1348 00010012 R_X86_64_TPOFF64 foo + 0
The above assembly is a simplification of
__attribute__((tls_model("initial-exec"))) static __thread int foo;
int *bar() {return &foo; }
--
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/18695] [x86-64] Missing relocation overflow check
https://sourceware.org/bugzilla/show_bug.cgi?id=18695 Rafael Ávila de Espíndola changed: What|Removed |Added CC||rafael.espindola at gmail dot com -- 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/18609] Invalid R_X86_64_GOTPCREL -> R_X86_64_PC32 conversions
https://sourceware.org/bugzilla/show_bug.cgi?id=18609 Rafael Ávila de Espíndola changed: What|Removed |Added CC||rafael.espindola at gmail dot com -- 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/18591] Invalid R_X86_64_GOTPCREL -> R_X86_64_PC32 conversions
https://sourceware.org/bugzilla/show_bug.cgi?id=18591 Rafael Ávila de Espíndola changed: What|Removed |Added CC||ccoutant at gmail dot com, ||rafael.espindola at gmail dot com --- Comment #2 from Rafael Ávila de Espíndola --- This bug is still present in gold -- 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/19140] __star_* and __stop_* symbols show up in dynamic relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=19140 --- Comment #5 from Rafael Ávila de Espíndola --- > > > Produces a R_X86_64_RELATIVE. Unfortunately that doesn't work with bfd. > > > > It works in my experiments. > > I should qualify that by saying it "works" in the sense that I see an > absolute R_X86_64_64 relocation instead of RELATIVE, but it ought to have > the same effect. That would still be a problem if multiple shared libraries have sections with the same name. Given that with gold one can use ".hidden __start_foo" to get the desired result, I would call the current behavior odd but workable, so no need to change. -- 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/19140] __star_* and __stop_* symbols show up in dynamic relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=19140 --- Comment #1 from Rafael Ávila de Espíndola --- The issue in gold can be avoided by making the declaration hidden: .section bar, "a" .hidden __start_bar .quad __start_bar Produces a R_X86_64_RELATIVE. Unfortunately that doesn't work with bfd. -- 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/19140] New: __star_* and __stop_* symbols show up in dynamic relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=19140 Bug ID: 19140 Summary: __star_* and __stop_* symbols show up in dynamic relocation Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: rafael.espindola at gmail dot com CC: ian at airs dot com Target Milestone: --- Given .long __start_bar - . .long __init_array_start - . .section bar,"a" gold complains about the first but not the second relocation when creating a shared library: ld: error: test.o: requires dynamic R_X86_64_PC32 reloc against '__start_bar' which may overflow at runtime; recompile with -fPIC bfd ld complains about both. Alternatively, given .quad __start_bar .quad __init_array_start .section bar,"a" gold creates a dynamic relocation for __start_bar but not __init_array_start. With bfd ld one gets dynamic relocations for both. Given what these symbols are, gold's behavior with __init_array_start seems the most reasonable. -- 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/19075] New: Archive member not fetched when strong undefined symbol found after a weak undef one
https://sourceware.org/bugzilla/show_bug.cgi?id=19075 Bug ID: 19075 Summary: Archive member not fetched when strong undefined symbol found after a weak undef one Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: rafael.espindola at gmail dot com CC: ian at airs dot com Target Milestone: --- Created attachment 8683 --> https://sourceware.org/bugzilla/attachment.cgi?id=8683&action=edit testcase I the attached testcase: * test1.s introduces an weak undefined reference to foo. * test2.s introduces a strong one * test3.s defines foo and is put in a library running ld test1.o --start-group test3.a test2.o --end-group works with bfd ld but not gold. Removing the weak undefined symbol from test1.s causes gold to fetch the member. -- 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/19031] R_386_PC32 does not imply a call
https://sourceware.org/bugzilla/show_bug.cgi?id=19031 --- Comment #4 from Rafael Ávila de Espíndola --- Created attachment 8665 --> https://sourceware.org/bugzilla/attachment.cgi?id=8665&action=edit x86_64 testcase -- 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/19031] New: R_386_PC32 does not imply a call
https://sourceware.org/bugzilla/show_bug.cgi?id=19031 Bug ID: 19031 Summary: R_386_PC32 does not imply a call Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: rafael.espindola at gmail dot com CC: amonakov at gmail dot com, bugdal at aerifal dot cx, hjl.tools at gmail dot com, ian at airs dot com Target Milestone: --- Created attachment 8652 --> https://sourceware.org/bugzilla/attachment.cgi?id=8652&action=edit testcase In order for function pointer comparisons to work when a non -fPIC non -fPIE program uses a shared library symbol the static linker has to create an undefined symbol with a value that points to the plt entry. Currently both gold and bfd ld assume that R_386_PC32 is a call and therefore doesn't capture the address, but there is no such guarantee in the psabi. The attached patch has two functions, g and h. g will get the function address of f using the GOT. h will get the function address of f using R_386_PC32. If f is linked in from a .o, both return the same value. If f is linked in from a .so one gets the body of f and another gets the plt entry. -- 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/19031] R_386_PC32 does not imply a call
https://sourceware.org/bugzilla/show_bug.cgi?id=19031 --- Comment #1 from Rafael Ávila de Espíndola --- Created attachment 8653 --> https://sourceware.org/bugzilla/attachment.cgi?id=8653&action=edit patch -- 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 binutils/15835] binutils can't deal with more than one SHT_SYMTAB_SHNDX section (such as from Solaris or illumos link editor)
https://sourceware.org/bugzilla/show_bug.cgi?id=15835 Rafael Ávila de Espíndola changed: What|Removed |Added CC||rafael.espindola at gmail dot com -- 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/18521] failing tests on fedora 22
https://sourceware.org/bugzilla/show_bug.cgi?id=18521 --- Comment #1 from Rafael Ávila de Espíndola --- Created attachment 8361 --> https://sourceware.org/bugzilla/attachment.cgi?id=8361&action=edit A self contained testcase of one of the test failures -- 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/18521] New: failing tests on fedora 22
https://sourceware.org/bugzilla/show_bug.cgi?id=18521 Bug ID: 18521 Summary: failing tests on fedora 22 Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: rafael.espindola at gmail dot com CC: ian at airs dot com Target Milestone: --- I just installed fedora 22 on a VM and I am getting the following test failures on 5d7908e0880030628536a0266968a15922574735: gold 0.1: testsuite/test-suite.log 9 of 222 tests failed. .. contents:: :depth: 2 FAIL: script_test_1 (exit: 134) === script_test_1: ../../../binutils/gold/testsuite/script_test_1.cc:42: int main(int, char**): Assertion `reinterpret_cast(&e) == &sym' failed. FAIL: script_test_11 (exit: 2) == FAIL: ifuncmain1 (exit: 139) FAIL: ifuncmain1pic (exit: 139) === FAIL: ifuncmain1vis (exit: 139) === FAIL: ifuncmain1vispic (exit: 139) == FAIL: ifuncmain1pie (exit: 139) === FAIL: ifuncmain1vispie (exit: 139) == FAIL: ifuncmain3 (exit: 139) -- 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/17498] gold includes far more symbols in symtab than bfd ld
https://sourceware.org/bugzilla/show_bug.cgi?id=17498
--- Comment #6 from Rafael Ávila de Espíndola ---
(In reply to Cary Coutant from comment #5)
> Testcase, please.
From the description:
$ cat test.cpp
void g(const char* x);
void f() {
g("aoeuaoeuaoeuao");
}
$ gcc -shared -fPIC test.cpp -o test.so -fuse-ld=bfd -O2 && nm test.so | grep
' r '
0728 r __FRAME_END__
$ gcc -shared -fPIC test.cpp -o test.so -fuse-ld=gold -O2 && nm test.so | grep
' r '
0760 r __FRAME_END__
06f5 r .LC0
note the extra .LC0 with gold.
> I'm not sure what you're asking for here, though. You want to make -X the
> default?
Yes, just have the some default for --discard-locals/-X as bfd ld.
--
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/17498] gold includes far more symbols in symtab than bfd ld
https://sourceware.org/bugzilla/show_bug.cgi?id=17498 Rafael Ávila de Espíndola changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- --- Comment #4 from Rafael Ávila de Espíndola --- Reopening per comment 2. -- 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/17498] gold includes far more symbols in symtab than bfd ld
https://sourceware.org/bugzilla/show_bug.cgi?id=17498 --- Comment #3 from Rafael Ávila de Espíndola --- (In reply to Cary Coutant from comment #2) > I believe this only matters because clang's integrated assembler doesn't > discard the ".L" symbols. Ideally, all those symbols can be dropped from the > .o files, and the linker won't need to discard them. That will save space > not only in the linker output, but also in all the .o files. > > If you build with --no-integrated-as, I bet you won't need --discard-locals. > > (This may have already been fixed in clang by now; I've reported the issue > earlier.) That is not the case. Note that clang is the *testcase*, not the compiler :-) The example in the description is using gcc. -- 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/18440] ICF depends on the section name to detect constructors and destructors
https://sourceware.org/bugzilla/show_bug.cgi?id=18440 --- Comment #2 from Rafael Ávila de Espíndola --- > > This unfortunately doesn't work if the compiler avoids producing the long > > section names (as llvm now can). > > Can we use the symbol name directly? That would be nice. Which is why I asked: > > Is there a convenient pass over the symbols that could be used for this > > instead? Looks like there is, could we use the walk done from Symbol_table::add_from_relob to check if a section has just a constructor in it? We already use that walk to mark symbols as gc roots. -- 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/18440] New: ICF depends on the section name to detect constructors and destructors
https://sourceware.org/bugzilla/show_bug.cgi?id=18440
Bug ID: 18440
Summary: ICF depends on the section name to detect constructors
and destructors
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com, tmsriram at google dot com
Target Milestone: ---
ICF has the following logic
// With --icf=safe, check if the mangled function name is a ctor
// or a dtor. The mangled function name can be obtained from the
// section name by stripping the section prefix.
if (parameters->options().icf_safe_folding()
&& !is_function_ctor_or_dtor(section_name)
&& (!target.can_check_for_function_pointers()
|| section_has_function_pointers(*p, i)))
{
continue;
}
This unfortunately doesn't work if the compiler avoids producing the long
section names (as llvm now can).
Is there a convenient pass over the symbols that could be used for this
instead?
--
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/18327] Exception frame merging is broken in gold
https://sourceware.org/bugzilla/show_bug.cgi?id=18327 Rafael Ávila de Espíndola changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Rafael Ávila de Espíndola --- Fixed in cfbf0e3c5b637d66b2b1aeadecae9c187b825b2f -- 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/18327] Exception frame merging is broken in gold
https://sourceware.org/bugzilla/show_bug.cgi?id=18327 --- Comment #4 from Rafael Ávila de Espíndola --- I should have a patch in a minute. -- 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/18327] Exception frame merging is broken in gold
https://sourceware.org/bugzilla/show_bug.cgi?id=18327 --- Comment #3 from Rafael Ávila de Espíndola --- A small assembly testcase: a.s: - .cfi_startproc .cfi_endproc --- b.s: -- .cfi_startproc .cfi_personality 3, __gxx_personality_v0 .cfi_endproc .cfi_startproc .cfi_endproc --- c.s: - .globl __gxx_personality_v0 .type __gxx_personality_v0,@function __gxx_personality_v0: -- gcc -c a.s gcc -c b.s gcc -c c.s ld c.o -shared -o c.so ld-new a.o b.o c.so -o t ld-old a.o b.o c.so -o t2 t will be missing a relocation to __gxx_personality_v0 -- 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/18327] Exception frame merging is broken in gold
https://sourceware.org/bugzilla/show_bug.cgi?id=18327 --- Comment #2 from Rafael Ávila de Espíndola --- I have bisected this to 67f95b96b4d5e8e19520d94bebae92db2f67af74 -- 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/17498] gold includes far more symbols in symtab than bfd ld
https://sourceware.org/bugzilla/show_bug.cgi?id=17498 --- Comment #1 from Rafael Ávila de Espíndola --- Looks like the difference is just the default value of discard_locals. With a current clang build: bfd: 63574408 bytes gold: 68768280 bytes gold --discard-locals: 63623736 bytes -- 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/17902] missing optimization: unused strings not deleted
https://sourceware.org/bugzilla/show_bug.cgi?id=17902 --- Comment #3 from Rafael Ávila de Espíndola --- (In reply to Clément Péron from comment #2) > Hi, > > Any Progress ? > > I made an ugly path to put each string in an unique section, > .rodata.str1.__hash__ > > it's working fine but string merging is impossible except if the strings are > identical. > > I think group strings depending on the function, like for .text sections > could be a good idea. I have a wip patch up for comments. I have split various cleanup that also speed up --gc-sections. Most of these are already in. -- 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/17902] missing optimization: unused strings not deleted
https://sourceware.org/bugzilla/show_bug.cgi?id=17902 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||ccoutant at gmail dot com -- 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/18152] [2.26 Regression] internal error in do_relocate_sections, at gold/reloc.cc:953
https://sourceware.org/bugzilla/show_bug.cgi?id=18152 --- Comment #3 from Rafael Ávila de Espíndola --- Created attachment 8201 --> https://sourceware.org/bugzilla/attachment.cgi?id=8201&action=edit self contained testcase This crashes: $ ld-new -shared -o foo.so -plugin ./LLVMgold.so foo.bc foo.o -- 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/18152] [2.26 Regression] internal error in do_relocate_sections, at gold/reloc.cc:953
https://sourceware.org/bugzilla/show_bug.cgi?id=18152 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||rafael.espindola at gmail dot com -- 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/18085] relocation overflow on SHF_MERGE if using -O2 on powerpc
https://sourceware.org/bugzilla/show_bug.cgi?id=18085 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||amodra at gmail dot com -- 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/18085] New: relocation overflow on SHF_MERGE if using -O2 on powerpc
https://sourceware.org/bugzilla/show_bug.cgi?id=18085 Bug ID: 18085 Summary: relocation overflow on SHF_MERGE if using -O2 on powerpc Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at google dot com Reporter: rafael.espindola at gmail dot com CC: ian at airs dot com $ cat t1.s ld 6,.LC121@toc@l(9) .section.rodata.str1.8,"aMS",@progbits,1 .LC121: .string ".cfi_startproc" $ cat t2.s .section.rodata.str1.8,"aMS",@progbits,1 .string "\t.cfi_startproc" $ gcc -c t1.s $ gcc -c t2.s $ ld -shared t1.o t2.o -o t $ ld -shared t1.o t2.o -o t -O2 t1.o(.text+0x2): error: relocation overflow -- 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/17931] --gc-sections doesn't work on section in a group
https://sourceware.org/bugzilla/show_bug.cgi?id=17931 --- Comment #4 from Rafael Ávila de Espíndola --- (In reply to Alan Modra from comment #3) > I hear what you're saying, and accept that gc-sections could be made to w ork > for the specific case you present here. However, I'm unconvinced that we > should do this in the linker, to work around what appears to be a gcc bug. I agree that this was originally a gcc bug (https://sourceware.org/bugzilla/show_bug.cgi?id=17931 for reference), bu t it is now an odd abi issue we have to live with. > We've kept groups together under gc-sections right from the initial > implementation of section group support in 2001. The major reason for do ing > this is to keep on-the-side sections, eg. debug info, when any of their > grouped code or data sections are kept. These on-the-side sections don't > have relocations from other sections that would cause them to be kept by the > usual gc-sections marking process. For an example of sections that appear > in a loaded image, exception handling info, .eh_frame and associated > sections, is another set of on-the-side sections that a compiler could pl ace > in a group (and should instead of relying on ld's eh_frame editing!). Yes, I would love to have the compiler output multiple .eh_frame sections in the correct comdat. I have implementing that in llvm in my todo list, but i t is low priority since every current linker has to handle the magical .eh_frame. > Are there similar on-the-side code sections that would prevent us making an > exception for code sections in a group? I don't know of any, but people do > weird things.. In a world where comdats are fully utilized, the only extra logic that is needed for GC is that some sections have relocations in the opposite direct ion: A .eh_frame should be kept if the function it points to is kept. The same g oes for debug info. It would be nice to have the "reverse reloc dependency" marked explicitly in the .o file (a new SHF_SIDE_TABLE maybe?), but adding it implicitly to a few well know sections seems a small cost for extra flexibility. -- 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/17931] --gc-sections doesn't work on section in a group
https://sourceware.org/bugzilla/show_bug.cgi?id=17931
Rafael Ávila de Espíndola cha
nged:
What|Removed |Added
CC||ccoutant at google dot com,
||rafael.espindola at gmail
dot com
--- Comment #2 from Rafael Ávila de Espíndola ---
(In reply to Alan Modra from comment #1)
> No, it should not be removed. See the gABI. "Therefore, such groups must
> be included or omitted from the linked object as a unit."
I believe there is a misunderstanding here.
Semantically, during the "regular" part of the link, the linker includes or
discards groups as a unit.
During the --gc-sections part, individual sections are considered.
Even without groups, --gc-sections would be "invalid" according to the spec,
since it drop sections that should be copied to the output. The point is th
at
--gc-sections is effectively an extension.
This does show up in the real world since the deleting destructor is
unfortunately part of D5:
struct foo {
virtual ~foo(){};
};
foo x;
produces with gcc 4.9:
.section.text._ZN3fooD2Ev,"axG",@progbits,_ZN3fooD5Ev,comdat
...
_ZN3fooD2Ev:
ret
.set_ZN3fooD1Ev,_ZN3fooD2Ev
.section.text._ZN3fooD0Ev,"axG",@progbits,_ZN3fooD5Ev,comdat
_ZN3fooD0Ev:
jmp _ZdlPv
Note that D0 is never equal to D1 or D2 since it has to call delete. If it
is
not used in a DSO, we bloat the binary.
--
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/17902] missing optimization: unused strings not deleted
https://sourceware.org/bugzilla/show_bug.cgi?id=17902 Rafael Ávila de Espíndola cha nged: What|Removed |Added Status|NEW |ASSIGNED Assignee|ccoutant at google dot com |rafael.espindola at gmail dot com --- Comment #1 from Rafael Ávila de Espíndola --- I am working on a patch. -- 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/17896] Plugin_manager::release_input_file leaks file descriptors
https://sourceware.org/bugzilla/show_bug.cgi?id=17896 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||rafael.espindola at gmail dot com -- 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/17902] New: missing optimization: unused strings not deleted
https://sourceware.org/bugzilla/show_bug.cgi?id=17902 Bug ID: 17902 Summary: missing optimization: unused strings not deleted Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at google dot com Reporter: rafael.espindola at gmail dot com CC: ian at airs dot com Created attachment 8090 --> https://sourceware.org/bugzilla/attachment.cgi?id=8090&action=edit testcase The attached testcase has a 3 strings: "foo", "bar", "bar". Only "foo" is used. Run $ gcc -c test.s $ ld test.o -o test.so --shared --gc-sections --icf=safe -O3 $ readelf -x .rodata test.so Hex dump of section '.rodata': 0x01e8 62617200 666f6f00 bar.foo. Note that gold merges the two "bar" entries, but fails to notice it can drop it completely. -- 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/17795] Initial-Exec to Local-Exec may change the previous instruction
https://sourceware.org/bugzilla/show_bug.cgi?id=17795 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||rafael.espindola at gmail dot com -- 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/17704] New: icf doesn't respect section alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=17704
Bug ID: 17704
Summary: icf doesn't respect section alignment
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at google dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Created attachment 8008
--> https://sourceware.org/bugzilla/attachment.cgi?id=8008&action=edit
testcase
With the attached testcase, running
gcc -c t1.s
ld -o foo t1.o
./foo
echo $?
ld -o foo t1.o --icf=safe
./foo
echo $?
Will print
0
1
The problem is that icf is merging foo and bar but not enforcing the stricter
alignment requirements of bar.
While this reduced testcase is assembly, the original was c++.
The check of the least significant bit of a function pointer comes from how
member functions are implemented:
* For non virtual functions, a plain pointer is passed.
* For virtual functions it is 1 + the vtable offset
To ensure that this works, the compiler has to align member functions, but has
no such requirement for regular functions. For example, given
struct S {
void f() { }
};
inline void g() {}
void f(S *x) {
g();
x->f();
}
gcc will align f but not g.
It is possible for a member function to codegen to the same bits as a
non-member function, which is how this bug was found.
--
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/17558] ld will follow DT_NEEDED when it is not necessary
https://sourceware.org/bugzilla/show_bug.cgi?id=17558 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||hjl.tools at gmail dot com -- 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/17558] New: ld will follow DT_NEEDED when it is not necessary
https://sourceware.org/bugzilla/show_bug.cgi?id=17558
Bug ID: 17558
Summary: ld will follow DT_NEEDED when it is not necessary
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rafael.espindola at gmail dot com
$ cat test3.c
void h(void) {
}
$ cat test2.c
void h(void);
void f(void) {
h();
}
$ cat test.c
void f(void);
int main(void) {
f();
}
$ gcc test3.c -fPIC -shared -o test3.so
$ gcc test2.c -fPIC -shared -o test2.so test3.so
$ gcc test.c -o test test2.so -fuse-ld=gold
$ gcc test.c -o test test2.so -fuse-ld=bfd
/home/espindola/inst/binutils/bin/ld.bfd: warning: test3.so, needed by
test2.so, not found (try using -rpath or -rpath-link)
test2.so: undefined reference to `h'
collect2: error: ld returned 1 exit status
But test.c doesn't use h or anything from test3.so at all. All that it needs is
test2.so and that has already been created.
--
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/17556] New: crashing when mixing SHF_ALLOC and non SHF_ALLOC sections
https://sourceware.org/bugzilla/show_bug.cgi?id=17556 Bug ID: 17556 Summary: crashing when mixing SHF_ALLOC and non SHF_ALLOC sections Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at google dot com Reporter: rafael.espindola at gmail dot com CC: ian at airs dot com $ cat test.s .section .foo,"" $ cat test2.s .section.foo,"a" bar: $ gcc -c test.s $ gcc -c test2.s $ ld -shared -o test.so test.o test2.o ld: internal error in add_output_section_to_load, at ../../binutils/gold/output.cc:4093 -- 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/17540] New: gold leaks processing an empty file
https://sourceware.org/bugzilla/show_bug.cgi?id=17540 Bug ID: 17540 Summary: gold leaks processing an empty file Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at google dot com Reporter: rafael.espindola at gmail dot com CC: ian at airs dot com $ echo > t.s $ gcc -c t.s $ valgrind --leak-check=full --show-leak-kinds=definite ld-new -shared t.o -o t.so ==9661== Memcheck, a memory error detector ==9661== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==9661== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==9661== Command: /home/espindola/binutils/build/gold/ld-new -shared t.o -o t.so ==9661== ==9661== ==9661== HEAP SUMMARY: ==9661== in use at exit: 344,338 bytes in 1,421 blocks ==9661== total heap usage: 2,025 allocs, 604 frees, 450,701 bytes allocated ==9661== ==9661== 32 bytes in 1 blocks are definitely lost in loss record 361 of 901 ==9661==at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==9661==by 0x6D61DC: operator new(unsigned long) (in /home/espindola/binutils/build/gold/ld-new) ==9661==by 0x592C59: gold::queue_final_tasks(gold::General_options const&, gold::Input_objects const*, gold::Symbol_table const*, gold::Layout*, gold::Workqueue*, gold::Output_file*) (gold.cc:810) ==9661==by 0x693704: gold::Workqueue::find_and_run_task(int) (workqueue.cc:319) ==9661==by 0x693A29: gold::Workqueue::process(int) (workqueue.cc:495) ==9661==by 0x406ADB: main (main.cc:252) ==9661== ==9661== 32 bytes in 1 blocks are definitely lost in loss record 362 of 901 ==9661==at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==9661==by 0x6D61DC: operator new(unsigned long) (in /home/espindola/binutils/build/gold/ld-new) ==9661==by 0x5928E6: gold::queue_final_tasks(gold::General_options const&, gold::Input_objects const*, gold::Symbol_table const*, gold::Layout*, gold::Workqueue*, gold::Output_file*) (gold.cc:818) ==9661==by 0x693704: gold::Workqueue::find_and_run_task(int) (workqueue.cc:319) ==9661==by 0x693A29: gold::Workqueue::process(int) (workqueue.cc:495) ==9661==by 0x406ADB: main (main.cc:252) ==9661== ==9661== 40 bytes in 1 blocks are definitely lost in loss record 583 of 901 ==9661==at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==9661==by 0x6D61DC: operator new(unsigned long) (in /home/espindola/binutils/build/gold/ld-new) ==9661==by 0x5C2C60: gold::Layout_task_runner::run(gold::Workqueue*, gold::Task const*) (layout.cc:392) ==9661==by 0x693704: gold::Workqueue::find_and_run_task(int) (workqueue.cc:319) ==9661==by 0x693A29: gold::Workqueue::process(int) (workqueue.cc:495) ==9661==by 0x406ADB: main (main.cc:252) ==9661== ==9661== LEAK SUMMARY: ==9661==definitely lost: 104 bytes in 3 blocks ==9661==indirectly lost: 0 bytes in 0 blocks ==9661== possibly lost: 27,190 bytes in 718 blocks ==9661==still reachable: 317,044 bytes in 700 blocks ==9661== suppressed: 0 bytes in 0 blocks ==9661== Reachable blocks (those to which a pointer was found) are not shown. ==9661== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==9661== ==9661== For counts of detected and suppressed errors, rerun with: -v ==9661== ERROR SUMMARY: 476 errors from 476 contexts (suppressed: 2 from 2) -- 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/17498] New: gold includes far more symbols in symtab than bfd ld
https://sourceware.org/bugzilla/show_bug.cgi?id=17498
Bug ID: 17498
Summary: gold includes far more symbols in symtab than bfd ld
Product: binutils
Version: 2.26 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at google dot com
Reporter: rafael.espindola at gmail dot com
CC: ian at airs dot com
Linking clang with gold produces a binary with 185552 symbols in .symtab. With
gnu ld, only 60018.
The result is that when using --strip-all both linkers produce binaries of
comparable sizes, but without it the one produced by gold is 4.3 MB bigger.
The entire difference seems to come from bfd hiding .L symbols:
$ cat test.cpp
void g(const char* x);
void f() {
g("aoeuaoeuaoeuao");
}
$ gcc -shared -fPIC test.cpp -o test.so -fuse-ld=bfd -O2 && nm test.so | grep
' r '
0728 r __FRAME_END__
$ gcc -shared -fPIC test.cpp -o test.so -fuse-ld=gold -O2 && nm test.so | grep
' r '
0760 r __FRAME_END__
06f5 r .LC0
--
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/17458] New: Symbol that normally exported from a binary reported as PREVAILING_DEF_IRONLY to a plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=17458 Bug ID: 17458 Summary: Symbol that normally exported from a binary reported as PREVAILING_DEF_IRONLY to a plugin Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at google dot com Reporter: rafael.espindola at gmail dot com CC: ian at airs dot com Created attachment 7814 --> https://sourceware.org/bugzilla/attachment.cgi?id=7814&action=edit testcase The attached testcase has a run.sh script. Running it on my machine prints 9: 00400508 0 FUNCGLOBAL DEFAULT 11 _init 11: 004006d4 0 FUNCGLOBAL DEFAULT 14 _fini 6: 0040064d 6 FUNCGLOBAL DEFAULT 13 bar 9: 00400508 0 FUNCGLOBAL DEFAULT 11 _init 11: 004006d4 0 FUNCGLOBAL DEFAULT 14 _fini The first run is using lto and the symbol bar is reported as PREVAILING_DEF_IRONLY which causes the plugin to drop it. On the second run -flto is not used and the linker keeps it in the main binary. When the program is executed, that is the symbol the dynamic linker will use. The testcase is sensitive to the versions used. If the commented line in the script is removed, the main binary symbol will have the same version as the one in the shared library and it is kept. It looks like all symbols of a given name are kept in the symbol table even if one with a preferred version is found. It is not clear if this is a bug or if the bug is telling the plugin the symbol is IRONLY. This is a reduced testcase from trying to override operator delete in the main binary. The same issue is present with gnu ld. -- 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/16773] Cannot process a R_X86_64_TPOFF32 against .tdata
https://sourceware.org/bugzilla/show_bug.cgi?id=16773 --- Comment #3 from Rafael Ávila de Espíndola --- (In reply to Cary Coutant from comment #2) > Fixed on trunk. > > How did you generate test.o? Can the compiler generate the relocation > against the .tdata section symbol, or did you do this through assembler? If > I can make a test case for this without resorting to assembly code, it wo uld > be nice. I found this (and pr16794) while trying to find out if llvm could produce t hese relocations. It worked with bfd, but not with gold. Thanks for fixing this bug. I will update the comment on llvm's source code so that it can start producing them at some point. -- 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/17366] gold can't handle a crt1.o with an .eh_frame
https://sourceware.org/bugzilla/show_bug.cgi?id=17366 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||jan.kratochvil at redhat d ot com --- Comment #1 from Rafael Ávila de Espíndola --- For what it is worth, crt1.o has an .eh_frame because of https://sourceware.org/ml/glibc-cvs/2012-q1/msg00415.html -- 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/17366] New: gold can't handle a crt1.o with an .eh_frame
https://sourceware.org/bugzilla/show_bug.cgi?id=17366 Bug ID: 17366 Summary: gold can't handle a crt1.o with an .eh_frame Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at google dot com Reporter: rafael.espindola at gmail dot com CC: ian at airs dot com I noticed that gold's exception_static_test test was failing on my machine (fedora 20 x86_64). The link line is gcctestdir/ld --build-id --no-add-needed --hash-style=gnu -m elf_x86_64 -static -o exception_static_test /usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtbeginT.o -Lgcctestdir -L/usr/lib/gcc/x86_64-redhat-linux/4.8.3 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../.. exception_test_main.o exception_test_1.o exception_test_2.o -ldl -lz -lstdc++ -lm --start-group -lgcc -lgcc_eh -lc --end-group /usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crtn.o To see the problem run: readelf -aW exception_static_test | grep -i eh_frame On my system the output is [16] .eh_frame PROGBITS004b60d8 0b60d8 00f5ec 00 A 0 0 8 00 .note.ABI-tag .note.gnu.build-id .rela.plt .init .plt .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata .gcc_except_table .stapsdt.base __libc_subfreeres __libc_atexit __libc_thread_subfreeres .eh_frame 2: 004c56c0 0 OBJECT LOCAL DEFAULT 16 __EH_FRAME_BEGIN__ note how __EH_FRAME_BEGIN__ points to the *end* of .eh_frame. with bfd ld I get [15] .eh_frame PROGBITS004b5d08 0b5d08 00f524 00 A 0 0 8 00 .note.ABI-tag .note.gnu.build-id .rela.plt .init .plt .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata .stapsdt.base __libc_subfreeres __libc_atexit __libc_thread_subfreeres .eh_frame .gcc_except_table 261: 004b5d38 0 OBJECT LOCAL DEFAULT 15 __EH_FRAME_BEGIN__ The difference of 0x30 from the start is accounted by the .eh_frame of crt1.o: $ readelf -SW /lib64/crt1.o | grep .eh_frame [ 5] .eh_frame PROGBITS 90 30 00 A 0 0 8 -- 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/17350] ld cannot handle .init_array mixed with comdat
https://sourceware.org/bugzilla/show_bug.cgi?id=17350 Rafael Ávila de Espíndola cha nged: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Rafael Ávila de Espíndola --- You are right. Sorry for the noise, I forgot this relocation was using Rela format and the value in the relocated position was not relevant. -- 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/17350] ld cannot handle .init_array mixed with comdat
https://sourceware.org/bugzilla/show_bug.cgi?id=17350 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||amodra at gmail dot com -- 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/17350] New: ld cannot handle .init_array mixed with comdat
https://sourceware.org/bugzilla/show_bug.cgi?id=17350 Bug ID: 17350 Summary: ld cannot handle .init_array mixed with comdat Product: binutils Version: 2.25 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: rafael.espindola at gmail dot com Created attachment 7770 --> https://sourceware.org/bugzilla/attachment.cgi?id=7770&action=edit testcase The attached testcase has a .init_array that is in a comdat. With gold $ ~/binutils/build/gold/ld-new -shared -o test.so test.o $ readelf -x .init_array test.so Hex dump of section '.init_array': 0x1468 9002 $ readelf -sDW test.so | grep FUNC 1 0: 0290 1 FUNCWEAK DEFAULT 7 f That is, .init_array points to the function f, as expected. With bfd ld: $ ~/binutils/build/ld/ld-new -shared -o test.so test.o [espindola@localhost llvm]$ readelf -x .init_array test.so Hex dump of section '.init_array': 0x00200268 The section has a null. As to why this is useful: In C++ when doing static initialization of a variable in a comdat we can put the .init_array in that comdat. That way the linker should keep only one copy. -- 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 binutils/17278] ld does not accept UTF8-encoded response files ('@file') on windows using mingw
https://sourceware.org/bugzilla/show_bug.cgi?id=17278 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||rafael.espindola at gmail dot com -- 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/17128] New: internal error in lock, at ../../binutils/gold/fileread.cc:295
https://sourceware.org/bugzilla/show_bug.cgi?id=17128 Bug ID: 17128 Summary: internal error in lock, at ../../binutils/gold/fileread.cc:295 Product: binutils Version: 2.25 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at google dot com Reporter: rafael.espindola at gmail dot com CC: ian at airs dot com Created attachment 7691 --> https://sourceware.org/bugzilla/attachment.cgi?id=7691&action=edit testcase Having a plugin call get_input_file on two handles that come from the same archive causes gold to try to lock the file twice and asserts. This might be related to bug 15660 since the file being lock might prevent it from being closed and cause us to run out of file descriptors. The attached testcase includes a dummy plugin that just records the handles passed to it in claim_file_hook and calls get_input_file with them in all_symbols_read_hook. -- 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/17081] gold produces static arm binary that crashes at startup
https://sourceware.org/bugzilla/show_bug.cgi?id=17081 --- Comment #3 from Rafael Ávila de Espíndola --- This reduces to a trivial link time problem: $ cat start.s .globl _start .type _start,#function _start: bl __rel_iplt_start .globl my_memcpy my_memcpy: .type my_memcpy, #gnu_indirect_function bx lr $ llvm-mc -triple=armv7-linux-gnueabihf start.s -o start.o -filetype=obj $ ld.gold -Bstatic start.o -o t Looks like gold in not creating __rel_iplt_start but bfd ld is. -- 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/17081] gold produces static arm binary that crashes at startup
https://sourceware.org/bugzilla/show_bug.cgi?id=17081 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||ccoutant at google dot com Component|gprof |gold Assignee|unassigned at sourceware dot org |ian at airs dot com -- 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 gprof/17081] New: gold produces static arm binary that crashes at startup
https://sourceware.org/bugzilla/show_bug.cgi?id=17081 Bug ID: 17081 Summary: gold produces static arm binary that crashes at startup Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gprof Assignee: unassigned at sourceware dot org Reporter: rafael.espindola at gmail dot com Created attachment 7654 --> https://sourceware.org/bugzilla/attachment.cgi?id=7654&action=edit testcase The testcase should be fairly self contained. I copied the system libraries form a fedora 20 arm system. There is a run.sh that links with both bfd ld and gold. The bfd linked program works, the gold one crashes at startup. -- 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 gas/16279] Need a way to create two COFF sections with the same name but different comdats
https://sourceware.org/bugzilla/show_bug.cgi?id=16279 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||ktietz70 at googlemail dot com -- 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/16773] New: Cannot process a R_X86_64_TPOFF32 against .tdata
https://sourceware.org/bugzilla/show_bug.cgi?id=16773 Bug ID: 16773 Summary: Cannot process a R_X86_64_TPOFF32 against .tdata 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 7501 --> https://sourceware.org/bugzilla/attachment.cgi?id=7501&action=edit testcase I was curious if R_X86_64_TPOFF32 would work if given .tdata and an offset instead of a regular symbol. I don't see a reason why it shouldn't, given that it is just an offset. It works with bfd ld, but not gold: $ gcc test.o -fuse-ld=bfd -o test && ./test; echo $? 42 $ gcc test.o -fuse-ld=gold -o test && ./test; echo $? Segmentation fault 139 -- 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 gas/16753] New: Inconsistent propagation of symbol types to derived symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=16753 Bug ID: 16753 Summary: Inconsistent propagation of symbol types to derived symbols Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: rafael.espindola at gmail dot com When the type of a symbol is changed, it may or may not be propagated symbols based on it. Given .type b, @object a = b b: .type b, @function The new type is propagated and we get 4: 0 FUNCLOCAL DEFAULT1 b 5: 0 FUNCLOCAL DEFAULT1 a but given .type b, @object b: a = b .type b, @function The new type is not propagated and we get 4: 0 FUNCLOCAL DEFAULT1 b 5: 0 OBJECT LOCAL DEFAULT1 a Tested with d3839ede057ef077667978dbd065e7b5702c9176. -- 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 gas/16753] Inconsistent propagation of symbol types to derived symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=16753 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||iains at sourceware dot org -- 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 gas/16694] gas does not accept ARM VFP registers in .cfi_offset directives
https://sourceware.org/bugzilla/show_bug.cgi?id=16694 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||rafael.espindola at gmail dot com -- 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 gas/16279] New: Need a way to create two COFF sections with the same name but different comdats
https://sourceware.org/bugzilla/show_bug.cgi?id=16279 Bug ID: 16279 Summary: Need a way to create two COFF sections with the same name but different comdats Product: binutils Version: unspecified Status: NEW Severity: enhancement Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: rafael.espindola at gmail dot com On ELF one can easily create two sections with the same name in different comdats: - .sectionfoo,"axG",@progbits,f,comdat .globl f f: ret .sectionfoo,"axG",@progbits,g,comdat .globl g g: ret - on COFF that is not possible since the .section directive doesn't include the comdat information (that is part of the .linkonce directive). This means that a compiler using gas needs to produce unique names, producing more complex .obj files than the ones produced by msvc, which, for example, have all c++ inline functions in sections named .text. The assembler included in LLVM solved this by allowing the information normally passed to .linkonce to be passed to .section itself: http://llvm.org/docs/Extensions.html#section-directive -- 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/15660] out of file descriptors and couldn't close any
https://sourceware.org/bugzilla/show_bug.cgi?id=15660 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||rafael.espindola at gmail dot com -- 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 binutils/15435] Gold rejects undefined weak hidden symbol
http://sourceware.org/bugzilla/show_bug.cgi?id=15435 Rafael Ávila de Espíndola cha nged: What|Removed |Added CC||rafael.espindola at gmail ||dot com -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 binutils/15435] Gold rejects undefined weak hidden symbol
http://sourceware.org/bugzilla/show_bug.cgi?id=15435 --- Comment #2 from Rafael Ávila de Espíndola 2013-05-06 19:09:08 UTC --- Created attachment 7016 --> http://sourceware.org/bugzilla/attachment.cgi?id=7016 Assembly testcase This reproduces with $ gcc test.s -o test.so -shared When using gold as the linker. When the linker is the bfd ld the undefined weak hidden symbol is resolved to null. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12488] plugins don't support linkonce
http://sourceware.org/bugzilla/show_bug.cgi?id=12488 Rafael Ávila de Espíndola changed: What|Removed |Added Summary|Fails with plugins and |plugins don't support |weak, hidden symbols|linkonce --- Comment #4 from Rafael Ávila de Espíndola 2011-02-14 06:36:37 UTC --- I noticed that the real problem is that plugins don't support linkonce. We select the symbol from the IL file but the section from the elf file :-) Shouldn't be too hard to add support, but I will try to get LLVM to use comdat instead. Should I close as wontfix? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
