[Bug gold/18322] gold doesn't support --compress-debug-sections={zlib-gabi|zlib-gnu}
https://sourceware.org/bugzilla/show_bug.cgi?id=18322 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ccoutant at gmail dot com |hjl.tools at gmail dot com Severity|normal |enhancement -- 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/18321] gold doesn't support SHF_COMPRESSED sections
https://sourceware.org/bugzilla/show_bug.cgi?id=18321 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ccoutant at gmail dot com |hjl.tools at gmail dot com Severity|normal |enhancement -- 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 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Cary Coutant --- Here's the patch that broke the test case: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=0916f9e741d6fd9dab4b0602bef034d01fa71650 I'm looking at 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/18348] Workaround ARM Cortex-A53 Errata 835769 & 843419
https://sourceware.org/bugzilla/show_bug.cgi?id=18348 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ccoutant at gmail dot com |shenhan at google 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/18365] GOLD: AArch64: produces broken dynamic executable
https://sourceware.org/bugzilla/show_bug.cgi?id=18365 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ccoutant at gmail dot com |shenhan at google dot com --- Comment #1 from Cary Coutant --- Did this only recently start failing? Han, can you take a look, please? -- 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/17819] gold crashes when generating build-id for a large .so
https://sourceware.org/bugzilla/show_bug.cgi?id=17819 --- Comment #4 from Cary Coutant --- > I have encountered this problem, too. > Is a patch coming soon, or should I pursue a workaround? I've been working on fixing this, but it's going to take some time. Workarounds are to use a different --build-id option (anything but "tree"), or to turn off --compress-debug-sections. (You can always use objcopy to compress the debug sections after the link if you need that.) -- 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/17819] gold crashes when generating build-id for a large .so
https://sourceware.org/bugzilla/show_bug.cgi?id=17819 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Cary Coutant --- Fixed on trunk. -- 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/15370] linker script does not group sections correctly when building ppc64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=15370 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Cary Coutant --- Fixed on trunk. -- 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/18378] Implement GOLD backend support for IBM z Systems
https://sourceware.org/bugzilla/show_bug.cgi?id=18378 --- Comment #5 from Cary Coutant --- Who should I assign this to? -- 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/18430] internal error in relocate_tls, at ../../binutils-2.25/gold/aarch64.cc:3695
https://sourceware.org/bugzilla/show_bug.cgi?id=18430 Cary Coutant changed: What|Removed |Added Assignee|ccoutant at gmail dot com |shenhan at google dot com --- Comment #2 from Cary Coutant --- A tarball containing all the inputs to the link, including the @-file would help. (You can add the -Wl,-t option to the c++ command to get a list of all the files that the linker reads.) If you also add the -v option to the c++ command, it'll show the actual linker command (probably 'collect2'). That would also be helpful. Are you using the --warn-unresolved-symbols option? It looks like this might be a reference to an unresolved TLS symbol. Alternatively, it could be a TLS relocation that refers to a non-TLS symbol, or a TLS symbol in a non-TLS section. The assertion you hit indicates that gold saw a TLS relocation but hadn't created a TLS segment yet. Gold will create a TLS segment whenever it sees a TLS section in an input file (i.e., a section with SHF_TLS set), or when it has any TLS common 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 gold/18307] gold/dwo fails compiling with LTO (output.h: 'addr' may be used unintialized)
https://sourceware.org/bugzilla/show_bug.cgi?id=18307
Cary Coutant changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Cary Coutant ---
This looks like a bogus complaint to me.
The error is flagged in Output_segment::set_addresses, called from
Layout::attach_allocated_section_to_segment, here:
// Check for --section-start.
uint64_t addr;
bool is_address_set = parameters->options().section_start(os->name(), &addr);
...
if (is_address_set)
oseg->set_addresses(addr, addr);
General_options::section_start looks like this:
bool
General_options::section_start(const char* secname, uint64_t* paddr) const
{
if (this->section_starts_.empty())
return false;
std::map::const_iterator p =
this->section_starts_.find(secname);
if (p == this->section_starts_.end())
return false;
*paddr = p->second;
return true;
}
So we only use addr if section_start returns true, in which case, it will have
initialized addr. GCC's flow analysis ought to be good enough to deal with
this.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18288] linker -s output suboptimal
https://sourceware.org/bugzilla/show_bug.cgi?id=18288 Cary Coutant changed: What|Removed |Added Status|NEW |WAITING --- Comment #16 from Cary Coutant --- I downloaded the tarball and tried to link, but get this: /usr/lib/gcc/x86_64-linux-gnu/4.8/lto1 -quiet -dumpdir .libs/ -dumpbase opendkim.wpa -mtune=generic -march=nocona -mtune=generic -march=x86-64 -auxbase opendkim-opendkim -O3 -version -fno-fat-lto-objects -fltrans-output-list=/tmp/ccLne9cm.ltrans.out -fwpa -fresolution=/tmp/ccDmo4Wi.res @/tmp/cc7y8f2m GNU GIMPLE (Ubuntu 4.8.2-19ubuntu1) version 4.8.2 (x86_64-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1 warning: MPFR header version 3.1.2-p3 differs from library version 3.1.2. warning: MPC header version 1.0.1 differs from library version 1.0.3. GGC heuristics: --param ggc-min-expand=96 --param ggc-min-heapsize=125406 GNU GIMPLE (Ubuntu 4.8.2-19ubuntu1) version 4.8.2 (x86_64-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1 warning: MPFR header version 3.1.2-p3 differs from library version 3.1.2. warning: MPC header version 1.0.1 differs from library version 1.0.3. GGC heuristics: --param ggc-min-expand=96 --param ggc-min-heapsize=125406 lto1: fatal error: LTO_tags out of range: Range is 0 to 368, value is 753 compilation terminated. lto-wrapper: gcc returned 1 exit status ../../gold/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status Do you have an example that doesn't involve -flto? -- 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/18308] Gold generate strange alignment on .bss section: 2109584 bytes
https://sourceware.org/bugzilla/show_bug.cgi?id=18308 Cary Coutant changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Cary Coutant --- http://mail.aegee.org/dpa/bz18288/strip/opendkim-gold2.25-unstripped gives "404 Not Found". Waiting for a reproducer. -- 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 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Cary Coutant --- 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.) -- 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 #5 from Cary Coutant --- Testcase, please. I'm not sure what you're asking for here, though. You want to make -X the default? -- 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 #7 from Cary Coutant ---
> $ 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.
Ah, gas doesn't discard that local because it's in a merge section.
> > 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.
Actually, Gnu ld's default is not -X. By default, it only discards local
symbols that are in merge sections (i.e., the only temporary locals that gas
doesn't discard).
To match Gnu ld, I'll need to add that behavior as the new default, and add a
--discard-none option.
--
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 Cary Coutant changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Cary Coutant --- Changed default behavior to discard temporary locals in merge sections, as Gnu ld does, and added --discard-none to keep all locals. Fixed on trunk. -- 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/18200] Failure trying to compile gold with latest released tarball (2.25)
https://sourceware.org/bugzilla/show_bug.cgi?id=18200 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Cary Coutant --- I've added a diststuff target to the gold Makefile on trunk. -- 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/11182] gold can't find a scripted INPUT when both script and input are in a subdirectory
https://sourceware.org/bugzilla/show_bug.cgi?id=11182 Cary Coutant changed: What|Removed |Added CC||ccoutant at gmail dot com Assignee|ian at airs dot com|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/18288] gold does not handle common symbols in shared libraries correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=18288 Cary Coutant changed: What|Removed |Added Status|WAITING |ASSIGNED Summary|linker -s output suboptimal |gold does not handle common ||symbols in shared libraries ||correctly --- Comment #20 from Cary Coutant --- The library libopendbx.so has an allocated common symbol: 24: 00203090 1 COMMON GLOBAL DEFAULT 23 __gnu_lto_v1 (This is a marker symbol emitted by GCC during LTO.) Gold is doing two things wrong here: (1) It's processing the symbol from the shared library as a normal common symbol, and trying to allocate a 1-byte common block with alignment of 0x203090. Instead, we should simply treat the symbol as a regular defined symbol. (2) In mistakenly taking the symbol's address as a requested alignment, we end up with some weird address layout because the alignment is not a multiple of the page size. That results in the unusually large alignment of the .bss section, and also results in the internal error in set_offset reported in the more recent comments. -- 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/18288] gold does not handle common symbols in shared libraries correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=18288 --- Comment #21 from Cary Coutant --- *** Bug 18308 has been marked as a duplicate of 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 gold/18308] Gold generate strange alignment on .bss section: 2109584 bytes
https://sourceware.org/bugzilla/show_bug.cgi?id=18308 Cary Coutant changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Cary Coutant --- *** This bug has been marked as a duplicate of bug 18288 *** -- 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/18288] gold does not handle common symbols in shared libraries correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=18288 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #23 from Cary Coutant --- Fixed on trunk. -- 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/17731] gold doesn't handle .debug_frame section: ld: internal error in set_section_addresses, at script-sections.cc:2491
https://sourceware.org/bugzilla/show_bug.cgi?id=17731
--- Comment #8 from Cary Coutant ---
(In reply to Markus Trippelsdorf from comment #5)
> Indeed with the following kernel patch "fixes" the issue for me:
>
> diff --git a/include/asm-generic/vmlinux.lds.h
> b/include/asm-generic/vmlinux.lds.h
> index bee5d683074d..68b80c7e9527 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -569,7 +569,6 @@
> .gnu.linkonce.wi.*) } \
> .debug_abbrev 0 : { *(.debug_abbrev) }\
> .debug_line 0 : { *(.debug_line) } \
> - .debug_frame0 : { *(.debug_frame) } \
> .debug_str 0 : { *(.debug_str) } \
> .debug_loc 0 : { *(.debug_loc) } \
> .debug_macinfo 0 : { *(.debug_macinfo) } \
I was seduced into thinking there was something special about .debug_frame
that set it apart from the other .debug sections listed above. But the only
thing that sets it apart is that it's the only one of those sections that
appears in any of the .o files the linker sees; it turns out that we'd have
had the same problem with any compressed debug sections. The patterns
are only recognizing uncompressed debug sections, so .zdebug_frame is
being left unmatched. We don't expect that to happen, and assert on the
unexpected condition.
Workaround would be to add the compressed names to the specs, as in:
.debug_frame0 : { *(.debug_frame .zdebug_frame) } \
Working on a fix...
--
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/16341] relative paths in ld.script break gold linker
https://sourceware.org/bugzilla/show_bug.cgi?id=16341 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Cary Coutant --- This is the same issue as PR 11182. *** This bug has been marked as a duplicate of bug 11182 *** -- 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/11182] gold can't find a scripted INPUT when both script and input are in a subdirectory
https://sourceware.org/bugzilla/show_bug.cgi?id=11182 Cary Coutant changed: What|Removed |Added CC||gideon at accursoft dot com --- Comment #5 from Cary Coutant --- *** Bug 16341 has been marked as a duplicate of 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 gold/17731] gold doesn't handle .debug_frame section: ld: internal error in set_section_addresses, at script-sections.cc:2491
https://sourceware.org/bugzilla/show_bug.cgi?id=17731 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Cary Coutant --- Should be fixed on trunk now. -- 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/18614] Common symbols with local binding are not allocated by the linker
https://sourceware.org/bugzilla/show_bug.cgi?id=18614 Cary Coutant changed: What|Removed |Added Priority|P2 |P3 --- Comment #1 from Cary Coutant --- What's the use case for local common symbols? It seems silly -- just allocate the space in .bss in the assembly. I'm more inclined to treat this bug report as a missing error message than as a failure to allocate the common. -- 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 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED 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/18614] Common symbols with local binding are not allocated by the linker
https://sourceware.org/bugzilla/show_bug.cgi?id=18614 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED -- 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 Cary Coutant changed: What|Removed |Added Assignee|ccoutant at gmail dot com |hjl.tools at gmail dot com --- Comment #1 from Cary Coutant --- I tried to assign this to Ilya, but bugzilla won't let me. -- 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/18596] hidden symbol warnings may fire even if a visible symbol is available
https://sourceware.org/bugzilla/show_bug.cgi?id=18596 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Cary Coutant --- Duplicate of PR 15574. *** This bug has been marked as a duplicate of bug 15574 *** -- 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/15574] Gold is overly pedantic for dynamic references to symbols with hidden visibility
https://sourceware.org/bugzilla/show_bug.cgi?id=15574 Cary Coutant changed: What|Removed |Added CC||danalbert at google dot com --- Comment #5 from Cary Coutant --- *** Bug 18596 has been marked as a duplicate of 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 gold/15574] Gold is overly pedantic for dynamic references to symbols with hidden visibility
https://sourceware.org/bugzilla/show_bug.cgi?id=15574 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Cary Coutant --- Fixed on master. -- 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/18698] internal error in target, at ../../binutils/gold/parameters.h:105
https://sourceware.org/bugzilla/show_bug.cgi?id=18698 Cary Coutant changed: What|Removed |Added CC||ccoutant at gmail dot com --- Comment #1 from Cary Coutant --- > Where is the proper place for initialization? gold doesn't set the target until it sees its first object file. In the case of an archive library as the first parameter, we have no way of knowing what the default entry point should be (because the entry point symbol is target specific). Parameters::entry() should first check that target has been set, and if not, simply return NULL. Library_base::should_include_member() should check for NULL, and either skip the check for the entry symbol, or print a warning that the -e option should be used when there is no startup file. -- 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/18698] internal error in target, at ../../binutils/gold/parameters.h:105
https://sourceware.org/bugzilla/show_bug.cgi?id=18698 Cary Coutant changed: What|Removed |Added Assignee|andrew.n.senkevich at gmail dot co |ccoutant at gmail dot com |m | --- Comment #3 from Cary Coutant --- When linking with -r, Gnu ld doesn't use the entry symbol, so gold shouldn't either. When linking without -r, gold needs to know the target in order to know the entry symbol, so if no target has been established, don't look for an entry symbol. -- 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/18698] internal error in target, at ../../binutils/gold/parameters.h:105
https://sourceware.org/bugzilla/show_bug.cgi?id=18698 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Cary Coutant --- Fixed on trunk. Sorry, I had a typo in the ChangeLog entry when I committed this. The actual commit that fixed the bug is here: https://sourceware.org/ml/binutils-cvs/2015-07/msg00142.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/18548] gold incorrectly exports start/stop symbols (GLOBAL)
https://sourceware.org/bugzilla/show_bug.cgi?id=18548 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Cary Coutant --- Fixed on trunk. -- 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/18703] Symbol version and Version script incompatibility with BFD ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18703
--- Comment #1 from Cary Coutant ---
You're looking at the linker symbol table with nm. (And nm does not show
versioning information from the .gnu.version* sections.)
When I build this with gold, readelf -Vs shows:
Symbol table '.dynsym' contains 13 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 NOTYPE WEAK DEFAULT UND __gmon_start__
2: 0 NOTYPE WEAK DEFAULT UND
_ITM_deregisterTMCloneTab
3: 0 FUNCWEAK DEFAULT UND
__cxa_finalize@GLIBC_2.2.5 (3)
4: 0 NOTYPE WEAK DEFAULT UND
_ITM_registerTMCloneTable
5: 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
6: 06f511 FUNCGLOBAL DEFAULT 12 foo@@VERS_1.1
7: 2018 0 NOTYPE GLOBAL DEFAULT ABS _edata
8: 2019 0 NOTYPE GLOBAL DEFAULT ABS _end
9: 05c0 0 FUNCGLOBAL DEFAULT 10 _init
10: 2018 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
11: 0700 0 FUNCGLOBAL DEFAULT 13 _fini
12: 0 OBJECT GLOBAL DEFAULT ABS VERS_1.1
...
Version symbols section '.gnu.version' contains 13 entries:
Addr: 0458 Offset: 0x000458 Link: 2 (.dynsym)
000: 0 (*local*) 0 (*local*) 0 (*local*) 3 (GLIBC_2.2.5)
004: 0 (*local*) 0 (*local*) 2 (VERS_1.1) 1 (*global*)
008: 1 (*global*) 1 (*global*) 1 (*global*) 1 (*global*)
00c: 2 (VERS_1.1)
Version definition section '.gnu.version_d' contains 2 entries:
Addr: 0x0474 Offset: 0x000474 Link: 3 (.dynstr) 00: Rev: 1
Flags: BASE Index: 1 Cnt: 1 Name: ver1.so
0x001c: Rev: 1 Flags: none Index: 2 Cnt: 1 Name: VERS_1.1
Version needs section '.gnu.version_r' contains 1 entries:
Addr: 0x04ac Offset: 0x0004ac Link: 3 (.dynstr)
00: Version: 1 File: libc.so.6 Cnt: 1
0x0010: Name: GLIBC_2.2.5 Flags: none Version: 3
I think this is working as intended, although comparing with Gnu ld output, I
see that gold defines it as a default version ("@@") where Gnu ld does not. I'm
not sure what the logic ought to be for that. Without the __asm__ in the .c
file, Gnu ld also makes it a default version.
--
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/18703] Symbol version and Version script incompatibility with BFD ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18703
--- Comment #3 from Cary Coutant ---
Sorry, I need more context than that. You've said that the symbol is
not versioned, but in fact it is. The only differences between the two
linkers that I see are:
(1) The name that appears in the linker symbol table, which shouldn't
matter to the loader at all. If this is causing a problem, can you
point to the section in the linker manual that describes the correct
behavior? I don't think gold was designed with the intent of
propagating @-style version information into the output binary. We
only use the version sections, and, as far as I know, the dynamic
loader only uses version sections.
(2) Gold defines the symbol as a default version, while Gnu ld
doesn't. If this is the problem, I'll need to understand what the
proper logic is for determining whether a symbol should be marked as
the default version.
You said this affects building libgcc_s.so in trunk, but you haven't
said what is actually failing.
-cary
On Tue, Jul 21, 2015 at 4:51 PM, tmsriram at google dot com
wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=18703
>
> --- Comment #2 from Sriraman Tallam ---
> On Tue, Jul 21, 2015 at 11:03 AM, ccoutant at gmail dot com
> wrote:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=18703
>>
>> --- Comment #1 from Cary Coutant ---
>> You're looking at the linker symbol table with nm. (And nm does not show
>> versioning information from the .gnu.version* sections.)
>>
>> When I build this with gold, readelf -Vs shows:
>>
>> Symbol table '.dynsym' contains 13 entries:
>>Num:Value Size TypeBind Vis Ndx Name
>> 0: 0 NOTYPE LOCAL DEFAULT UND
>> 1: 0 NOTYPE WEAK DEFAULT UND __gmon_start__
>> 2: 0 NOTYPE WEAK DEFAULT UND
>> _ITM_deregisterTMCloneTab
>> 3: 0 FUNCWEAK DEFAULT UND
>> __cxa_finalize@GLIBC_2.2.5 (3)
>> 4: 0 NOTYPE WEAK DEFAULT UND
>> _ITM_registerTMCloneTable
>> 5: 0 NOTYPE WEAK DEFAULT UND
>> _Jv_RegisterClasses
>> 6: 06f511 FUNCGLOBAL DEFAULT 12 foo@@VERS_1.1
>> 7: 2018 0 NOTYPE GLOBAL DEFAULT ABS _edata
>> 8: 2019 0 NOTYPE GLOBAL DEFAULT ABS _end
>> 9: 05c0 0 FUNCGLOBAL DEFAULT 10 _init
>> 10: 2018 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
>> 11: 0700 0 FUNCGLOBAL DEFAULT 13 _fini
>> 12: 0 OBJECT GLOBAL DEFAULT ABS VERS_1.1
>>
>> ...
>>
>> Version symbols section '.gnu.version' contains 13 entries:
>> Addr: 0458 Offset: 0x000458 Link: 2 (.dynsym)
>> 000: 0 (*local*) 0 (*local*) 0 (*local*) 3
>> (GLIBC_2.2.5)
>> 004: 0 (*local*) 0 (*local*) 2 (VERS_1.1) 1 (*global*)
>> 008: 1 (*global*) 1 (*global*) 1 (*global*) 1 (*global*)
>> 00c: 2 (VERS_1.1)
>>
>> Version definition section '.gnu.version_d' contains 2 entries:
>> Addr: 0x0474 Offset: 0x000474 Link: 3 (.dynstr) 00:
>> Rev: 1
>> Flags: BASE Index: 1 Cnt: 1 Name: ver1.so
>> 0x001c: Rev: 1 Flags: none Index: 2 Cnt: 1 Name: VERS_1.1
>>
>> Version needs section '.gnu.version_r' contains 1 entries:
>> Addr: 0x04ac Offset: 0x0004ac Link: 3 (.dynstr)
>> 00: Version: 1 File: libc.so.6 Cnt: 1
>> 0x0010: Name: GLIBC_2.2.5 Flags: none Version: 3
>>
>> I think this is working as intended, although comparing with Gnu ld output, I
>> see that gold defines it as a default version ("@@") where Gnu ld does not.
>> I'm
>> not sure what the logic ought to be for that. Without the __asm__ in the .c
>> file, Gnu ld also makes it a default version.
>
> Some context:
>
> https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00878.html
>
> This was used to hide symbols __cpu_indicator_init and __cpu_model
> defined in libgcc_s.so so that this symbol is always obtained from
> libgcc.a. Now, this works with GNU ld and not with gold. Isnt this an
> incompatibility. If this is not well defined, is there another well
> defined way of achieving the same result?
>
> Thanks
> Sri
>
>
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the 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 gold/18703] Symbol version and Version script incompatibility with BFD ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18703 --- Comment #6 from Cary Coutant --- >Another usage of the '.symver' directive is: > .symver NAME, NAME2@@NODENAME >In this case, the symbol NAME must exist and be defined within the > file being assembled. It is similar to NAME2@NODENAME. The difference > is NAME2@@NODENAME will also be used to resolve references to NAME2 by > the linker. > > Linker shouldn't use foo@VERS_1.1 to resolve references to foo. Yes, I understand that much. The example given uses: .symver foo, foo@VERS_1.1 where the original symbol and the versioned symbol both have the same name. This produces two symbols in the .o file named "foo": T foo T foo@VERS_1.1 With the version script, gold sees the first of those (plain "foo") and makes it the default version (as, I think, it should). The second one is just seen as a second declaration, but it's already been marked the default. If I change Sri's example to use ".symver orig_foo, foo@VERS_1.1" and rename "foo" to "orig_foo", I get the following in the dynamic symbol table: 6: 072511 FUNCGLOBAL DEFAULT 12 foo@VERS_1.1 7: 072511 FUNCGLOBAL DEFAULT 12 orig_foo If it's the "@@" vs. "@" that's causing the problem, then there's your fix. -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/18703] Symbol version and Version script incompatibility with BFD ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18703 --- Comment #10 from Cary Coutant --- >> T foo >> T foo@VERS_1.1 >> >> With the version script, gold sees the first of those (plain "foo") >> and makes it the default version (as, I think, it should). The second >> one is just seen as a second declaration, but it's already been marked >> the default. > > foo is versioned and only version specified is VERS_1.1, which is not > default version. It is wrong to create a default foo without being asked > to do so. In this example, "foo" is both unversioned and versioned. In response to the unversioned one, gold is creating a default version, as directed by the linker script. If "foo@VERS_1.1" were the only version of "foo" in this file, gold would not make it a default version. If you don't want a default version, get rid of the first, unversioned, "foo", and gold will do what you expect. I've played around with a bunch of different combinations, and I can't even begin to unravel the logic behind Gnu ld's behavior when there are multiple instances of versioned and unversioned symbols. I have no desire to try to reproduce its behavior beyond what's described in the documentation. -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/18521] failing tests on fedora 22
https://sourceware.org/bugzilla/show_bug.cgi?id=18521 Cary Coutant changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from Cary Coutant --- *** Bug 18628 has been marked as a duplicate of 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 gold/18628] gold IFUNC testsuite failures with GCC 5
https://sourceware.org/bugzilla/show_bug.cgi?id=18628 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Cary Coutant --- Duplicate of PR 18521. *** This bug has been marked as a duplicate of bug 18521 *** -- 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/18663] gold/testsuite/script_test_1.cc is incompatible with GCC 5
https://sourceware.org/bugzilla/show_bug.cgi?id=18663 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Cary Coutant --- (Why do I have to type something here?) Duplicate of PR 18521. *** This bug has been marked as a duplicate of bug 18521 *** -- 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 #3 from Cary Coutant --- *** Bug 18663 has been marked as a duplicate of 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 gold/18521] failing tests on fedora 22
https://sourceware.org/bugzilla/show_bug.cgi?id=18521 --- Comment #5 from Cary Coutant --- Sigh. This bug isn't really a duplicate of PR 18628 (it's really 18268 that duplicates a subset of this one). Let's consider this bug split into PR 18628 (for the IFUNC failures) and PR 18863 (for the script_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/18703] Symbol version and Version script incompatibility with BFD ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18703
--- Comment #12 from Cary Coutant ---
> The documentation can have some improvements. But ld.bfd behavior is
> well-defined as shown by testcases in ld/testsuite/ld-elfvers.
If you're going to maintain that ".symver foo,foo@VER" is valid, then I think
the assembler needs to be fixed so that it doesn't assume that the original
name and the versioned name don't have the same base. In obj-elf.c,
elf_frob_symbol seems to be written with the assumption that they are
different. The following patch fixes that so that we don't get the duplicate
symbol:
diff --git a/gas/config/obj-elf.c b/gas/config/obj-elf.c
index 78dc6d9..8668be0 100644
--- a/gas/config/obj-elf.c
+++ b/gas/config/obj-elf.c
@@ -2182,6 +2182,11 @@ elf_frob_symbol (symbolS *symp, int *puntp)
memmove (&p[2], &p[3], l);
S_SET_NAME (symp, sy_obj->versioned_name);
}
+ else if (strncmp (S_GET_NAME (symp), sy_obj->versioned_name,
+ strlen (S_GET_NAME (symp))) == 0)
+ {
+ S_SET_NAME (symp, sy_obj->versioned_name);
+ }
else
{
symbolS *symp2;
(testsuite/gas/elf/symver.d and testsuite/gas/symver/symver1.d will also need
adjusting.)
With that patch to gas, gold now has the same behavior for Sri's test case (and
it also passes the vers27d1.c test case in the ld testsuite).
Shall I forward this bug to gas? As long as gas is emitting an unversioned
symbol, I'm going to maintain that gold is doing the right thing in assigning
it a default version.
--
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/18703] Symbol version and Version script incompatibility with BFD ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18703
--- Comment #18 from Cary Coutant ---
Another change you can make is to remove "foo" from the version script
entirely. If foo.map is just this:
VERS_1.1 {
};
then both linkers will put "foo@VERS_1.1" into the dynamic symbol
table (no default version).
If you're going to use .symver to set the version, there's really no
point in also using a version script to do the same thing. It just
sets up a conflicting situation where different linkers might give
different behaviors.
-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/18703] Symbol version and Version script incompatibility with BFD ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18703
--- Comment #19 from Cary Coutant ---
> FAIL: vers1
This is because gold does not handle "sym@" properly. Working on it.
> FAIL: vers2
> FAIL: vers3
> FAIL: vers6
> FAIL: vers8
These look like the same root problem.
> ERROR: tcl error sourcing library file
> /export/gnu/import/git/sources/binutils-gdb/ld/testsuite/lib/../ld-elfvers/
> vers.exp.
> cp: cannot stat 'tmpdir/vers1.so': No such file or directory
> cp: cannot stat 'tmpdir/vers1.so': No such file or directory
> while executing
> "exec cp $tmpdir/$srclib $tmpdir/$libname.so"
> (procedure "test_strip_vers_lib" line 11)
> invoked from within
> "test_strip_vers_lib "vers14" vers1.so vers14 vers1.ver vers1.dsym"
> (file
> "/export/gnu/import/git/sources/binutils-gdb/ld/testsuite/lib/../ld-elfvers/
> vers.exp" line 893)
> invoked from within
> "source
> /export/gnu/import/git/sources/binutils-gdb/ld/testsuite/lib/../ld-elfvers/
> vers.exp"
> ("uplevel" body line 1)
> invoked from within
> "uplevel #0 source
> /export/gnu/import/git/sources/binutils-gdb/ld/testsuite/lib/../ld-elfvers/
> vers.exp"
> invoked from within
> "catch "uplevel #0 source ${dir}/${initfile}" error"
> Makefile:3506: recipe for target 'check-DEJAGNU' failed
Not sure what this is. Looks more like a problem with the dejagnu 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 ld/18720] No symbol version section for versioned symbol `foo@FOO'
https://sourceware.org/bugzilla/show_bug.cgi?id=18720 Cary Coutant changed: What|Removed |Added CC||ccoutant at gmail dot com --- Comment #1 from Cary Coutant --- With my proposed fix for gas (see PR 18703 comment #12), indirect3b.o would not have the stray unversioned definition for foo, and ld would work just fine as is. https://sourceware.org/bugzilla/show_bug.cgi?id=18703#c12 With your testcase, gold binds to the unversioned foo in indirect3b.o, and the resulting binary prints "MAIN" twice. With the patched assembler, both gold and ld print "DSO" 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/18834] Gold does not accept linker-script input only with -T
https://sourceware.org/bugzilla/show_bug.cgi?id=18834 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Cary Coutant --- For the broader context, see the discussion at PR ld/18836. As far as this specific complaint goes, the behavior is as expected. If the script does not specify any input files, gold will complain about no input files. If you add an INPUT(foo.o) command to the script (and link it as an input file, not with -T), it will correctly read foo.o as an input file. I think the complaint here is that Gnu ld, if it sees an input section specification that names a file without a wildcard, will process that file as if it had been named on the command line. That seems like a misfeature to me -- all other uses of a filename in a SECTIONS clause are as a filter. Without a compelling use case, I'd prefer to keep gold's behavior as is. (See the aforementioned discussion at PR 18836 for why even the Gnu ld behavior is probably not what you're looking for.) -- 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/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear
https://sourceware.org/bugzilla/show_bug.cgi?id=18836
Cary Coutant changed:
What|Removed |Added
CC||ccoutant at gmail dot com
--- Comment #12 from Cary Coutant ---
> I think you should write down exactly what you need so that we can
> take a look at what linker, linker plugin and assembler should do.
I agree. This discussion also applies (at least in part) to PR gold/18834 and
PR gold/18837, so for the time being, lets talk about all three PRs here.
Here's my understanding of what you're trying to do; please correct me where
I've got it wrong:
It sounds like you want to emit early and full debug in an LTO intermediate --
either fat or slim -- and then emit only late debug info in the LTRANS output.
(a) If you're linking with fat LTO objects and no LTO, you want to ignore the
early debug info, and link only the full debug info. Thus, you're putting the
early debug info into .gnu.lto_ sections, so they get ignored by default in a
non-LTO link.
(b) If you're linking with LTO, you want to go pick up the early debug info
from the LTO intermediate (without picking up any other sections from that
object), and add to that the late debug info from the LTRANS output.
For (b) to work, you seem to be hoping that writing a linker script with
something like this in it will pick up *just* the early debug info from t.o:
SECTIONS {
.debug_info : { t.o(.gnu.lto_.debug_info) }
.debug_abbrev : { t.o(.gnu.lto_.debug_abbrev) }
.debug_str : { t.o(.gnu.lto_.debug_str) }
}
Sorry, but I don't think that's going to do what you think it will do.
According to the linker manual, even if t.o isn't listed on the command line,
ld will link t.o as if it had been named on the command line. As a result,
you'll link all sections from t.o, including the fat text and data sections.
(Not to mention that gold does not implement this particular misfeature -- if
t.o isn't named on the command line, gold will not add it to the list of input
files.)
In order to get the early debug info from the LTO intermediate, you're going to
have to copy it into one of the LTRANS output .o files, and rename the section
such that it doesn't get excluded by default.
Using a linker script for this seems like a bad idea anyway. It would be a lot
cleaner to extend the plugin API to add whatever features you need, and we
probably should have been discussing that before you got this far.
Stepping back a bit, it sounds to me like you should be using split DWARF
instead. With split DWARF, the debug info in the .dwo sections, which gets
split into separate .dwo files, is pretty much all early debug info. The parts
remaining in the .o are late debug info, so the split has already been done,
and there's no need to try to get the linker to extract individual sections
from an LTO intermediate.
--
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/18837] gold does not handle linker-scripts with inputs
https://sourceware.org/bugzilla/show_bug.cgi?id=18837 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Cary Coutant --- Let's use PR 18836 for a broader discussion on the topic of LTO and early debug. With the given script, Gnu ld will link t.o as if it had been named on the command line. Gold will not; we treat the filenames (with or without wildcards) as filters, and gold will not link a file unless it's given on the command line or in an INPUT command in a linker script. In addition, gold does not support partial linker scripts. If you have a linker script with a SECTIONS clause, you'll need to provide a complete description of the output section, or the final output will almost certainly not be usable. -- 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/18703] Symbol version and Version script incompatibility with BFD ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18703 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #21 from Cary Coutant --- Fixed on trunk. -- 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/18847] Gold: Address of section moves backward when aligned.
https://sourceware.org/bugzilla/show_bug.cgi?id=18847 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Cary Coutant --- Can you please post a small repro, with either source or object files, and a link command? -- 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/18845] Using emit-relocs and icf ends in assert fail.
https://sourceware.org/bugzilla/show_bug.cgi?id=18845 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Cary Coutant --- We never actually intended to support --gc-sections or --icf with -r links, but we don't do anything to disallow the combination, leading to the internal error. Gold should have some code in General_options::finalize() to disallow it. With --emit-relocs, however, there really is no reason to disallow the combination, so we should make it work. (Out of curiosity, what are you using --emit-relocs for? I'm not complaining -- hardly anyone uses the option, so it hasn't had much real-world 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/18837] gold does not handle linker-scripts with inputs
https://sourceware.org/bugzilla/show_bug.cgi?id=18837
--- Comment #4 from Cary Coutant ---
> I see. So I'm trying (same input):
>
> SECTIONS {
> .debug_info 0 : { *(.gnu.lto_.debug_info*) }
> .debug_abbrev 0 : { *(.gnu.lto_.debug_abbrev*) }
> .debug_str 0 : { *(.gnu.lto_.debug_str*) }
> /DISCARD/ : { *(*) }
> }
>
>> ld.gold -o x -T script t.o -r
> Segmentation fault
Hmm. This seems to be due to the fact that gold is trying to create
relocation sections for each of the new sections, but the script is
preventing it from doing so (add --debug=script to see it complain
about sections it's prevented from creating). Then we go on and assume
that we have a valid output section for the relocations and end up
segfaulting when we try to dereference the null pointer. Two bugs: (a)
gold should not let the /DISCARD/ clause prevent it from creating
relocation sections; and (b) it should be more careful to assert that
the pointer is not null before dereferencing.
I think you can get it to work by adding additional section
specifications something like this:
SECTIONS {
.debug_info 0 : { *(.gnu.lto_.debug_info*) }
.debug_abbrev 0 : { *(.gnu.lto_.debug_abbrev*) }
.debug_str 0 : { *(.gnu.lto_.debug_str*) }
.rela.debug_info 0 : { *(.rela.debug_info) }
.rela.debug_abbrev 0 : { *(.rela.debug_abbrev) }
.rela.debug_str 0 : { *(.rela.debug_str) }
/DISCARD/ : { *(*) }
}
>> ld.gold -o x -T script t.o
> t.o: plugin needed to handle lto object
That's just a (hopefully) helpful message we print when we see the
symbol "__gnu_lto_slim". It's informational only.
> ld.gold: internal error in address, at ../../gold/output.h:72
Not sure what this is caused by. I'm not seeing it with a top-of-trunk
linker. (But I'm also trying a much simpler test case, so maybe I
haven't recreated your scenario closely enough.)
> maybe you can help me writing a linker script that works with GOLD and
> a partial link (and also suggest how to drop the 'E'xclude bit during
> that link)? golds "error" messages are not exactly helpful :/
Sorry, can't help you with the SHF_EXCLUDE flag. There's no way that I
know of today to have the linker ignore that flag. Doing this will
probably require additional support in the linker(s), which would
probably be best done via an extension to the plugin API rather than
the scripting language.
-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/18859] Gold linker does not fully respect -no-as-needed
https://sourceware.org/bugzilla/show_bug.cgi?id=18859 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Cary Coutant --- > Gold and ld behave differently when a shared library is first mentioned when > -as-needed is in effect, and then again after -no-as-needed. Ld generates a > DT_NEEDED entry for such library, and gold does not. Why are you expecting a NEEDED entry for libutil? There's nothing in your main program that depends on anything in that library, so by the definition of the --as-needed option, gold is doing exactly what I would expect. Your command line lists "-lutil" twice, once between the as-needed options, and once after. Gold ignores any shared library listed on the command line that it has already processed. If you want the library in your DT_NEEDED list, remove the first copy from your command line (the one between --as-needed and --no-as-needed). -- 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/18855] String constants mixed up when linked with gold on Linux/sparc64
https://sourceware.org/bugzilla/show_bug.cgi?id=18855 --- Comment #1 from Cary Coutant --- Sorry, I don't have a SPARC development environment, so to investigate this, I'm going to need all the .o files (real .o files, not LTO intermediates). Does it still fail without -flto? Can you add -Wl,--stats to the command line and attach the output? -- 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/14746] ld: internal error in address, at gold/output.h:72 while building Linux kvm tool
https://sourceware.org/bugzilla/show_bug.cgi?id=14746
--- Comment #8 from Cary Coutant ---
> What I had to do to reproduce it was to add a symbol in my linker script
> that pointed to the address of .eh_frame. It's the same assert but I'm not
> sure that it's the same problem.
>
> Repo:
> test.c
> main(){ return 0; }
>
> g++ -c -o test.o test.c
>
> test.o need to contain an eh_frame.
>
> ld.gold -T script.lcf test.o
> ld.gold: internal error in address, at ../../gold/output.h:73
This is a different problem. In the original case, gold was trying to allocate
something in a discarded section. I don't expect that case to work, but it does
need a better diagnostic.
In this case, the .eh_frame section isn't discarded, but we're trying to get
its address before it's been computed (since .eh_frame is a linker-optimized
section, it hasn't been finalized yet). This case really ought to work.
--
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/14754] referring to undefined symbol results in internal error instead of helpful error message
https://sourceware.org/bugzilla/show_bug.cgi?id=14754 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ian at airs dot com|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/18859] Gold linker does not fully respect -no-as-needed
https://sourceware.org/bugzilla/show_bug.cgi?id=18859 Cary Coutant changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #3 from Cary Coutant --- OK, I have a patch in the works to have gold mark the shared object as --no-as-needed if it appears anywhere on the command line when --no-as-needed is in effect. As an aside, though, have you considered using --wrap for your wrapper functions? Your use case is exactly what that option was designed for. -- 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/18348] Workaround ARM Cortex-A53 Errata 835769 & 843419
https://sourceware.org/bugzilla/show_bug.cgi?id=18348 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||ccoutant at gmail dot com Resolution|--- |FIXED --- Comment #2 from Cary Coutant --- Fixed on trunk. These patches fixed 843419: https://sourceware.org/ml/binutils-cvs/2015-04/msg00152.html https://sourceware.org/ml/binutils-cvs/2015-04/msg00227.html https://sourceware.org/ml/binutils-cvs/2015-06/msg00076.html https://sourceware.org/ml/binutils-cvs/2015-06/msg00188.html https://sourceware.org/ml/binutils-cvs/2015-07/msg00134.html https://sourceware.org/ml/binutils-cvs/2015-07/msg00051.html This patch fixed 935769: https://sourceware.org/ml/binutils-cvs/2015-06/msg00090.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/18430] internal error in relocate_tls, at ../../binutils-2.25/gold/aarch64.cc:3695
https://sourceware.org/bugzilla/show_bug.cgi?id=18430 Cary Coutant changed: What|Removed |Added Status|NEW |WAITING CC||ccoutant at gmail dot com --- Comment #3 from Cary Coutant --- Waiting for more data from the reporter. -- 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/18865] ICF --keep-unique doesn't work correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=18865 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ccoutant at gmail dot com |tmsriram at google 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/18866] internal error in is_default, symtab.h:134
https://sourceware.org/bugzilla/show_bug.cgi?id=18866 --- Comment #3 from Cary Coutant --- I have absolutely no idea what to do with that attachment. HJ, what is it? It downloads as "lto.bc", and contains random garbage. -- 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/18866] internal error in is_default, symtab.h:134
https://sourceware.org/bugzilla/show_bug.cgi?id=18866 --- Comment #4 from Cary Coutant --- > I have absolutely no idea what to do with that attachment. HJ, what is it? > It downloads as "lto.bc", and contains random garbage. Oh, I see it's a bitcode file. I need .o files, please. -- 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/14187] gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss
https://sourceware.org/bugzilla/show_bug.cgi?id=14187 --- Comment #3 from Cary Coutant --- We've discussed fixing this before, but we now have legacy scripts that invoke gold with decimal values, and changing it would break them. We could certainly peek at the number and treat it as hex if it has any A-F digits, but that still wouldn't catch options like -Ttext=1. We could further favor hex over decimal unless it looks like a power of two when treated as decimal (or an integer multiple of some large power of two), but that's straying into dangerously unpredictable territory. The bottom line is that I don't have a good idea for how to fix this to match the Gnu ld documentation without breaking something. What's difficult about adding the "0x" so that it works with both linkers? -- 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/18866] internal error in is_default, symtab.h:134
https://sourceware.org/bugzilla/show_bug.cgi?id=18866 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Cary Coutant --- Fixed on master. -- 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/18859] Gold linker does not fully respect -no-as-needed
https://sourceware.org/bugzilla/show_bug.cgi?id=18859 Cary Coutant changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Cary Coutant --- Fixed on master. -- 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/18847] Gold: Address of section moves backward when aligned.
https://sourceware.org/bugzilla/show_bug.cgi?id=18847 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Cary Coutant --- Fixed on master. The actual fix was a bit more complicated, as we had to account for updating the location counter within the specified region and checking that the specified address is actually contained within the region. As an aside, the original script would have worked fine with one simple change. As written, .data ALIGN(0x1) : the ALIGN() expression specifies the section start address, which gold took to override the region specification. By writing this instead: .data : ALIGN(0x1) the ALIGN() expression is an alignment property of the output section rather than a section start address, and gold produces correct output even without the fix. -- 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/14187] gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss
https://sourceware.org/bugzilla/show_bug.cgi?id=14187 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ian at airs dot com|ccoutant at gmail dot com --- Comment #11 from Cary Coutant --- Created attachment 8557 --> https://sourceware.org/bugzilla/attachment.cgi?id=8557&action=edit Patch to fix gold to parse -Ttext, etc., options as hex numbers The attached patch changes gold to parse the -Ttext, etc., values as hex numbers, but will print a warning if it sees a value that looks more like a decimal number (in order to catch legacy uses). -- 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/14187] gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss
https://sourceware.org/bugzilla/show_bug.cgi?id=14187 --- Comment #12 from Cary Coutant --- > sure, it was first released in binutils-2.19 which was ~Oct 2008 (3 years > before the grub report), but i don't think people generally started using it > until later: it required distros to update, and i think we can agree that it > was another release or two before it could be used as more of a drop in vs > project specific one-offs. > Gentoo: May 2009 > Fedora: Nov 2009 (F13) > > i don't have an opinion on the various behaviors of -T, but i think the > number parsing should be the same, and gold should be the one to change > (even though it kind of sucks). accepting addresses in decimal is just > weird tbh. If I remember correctly, there were some legacy uses of gold within Google that used decimal parameters; those are the users I was concerned about. Maybe accepting addresses in decimal is weird, but I think it's weirder that only a few options default to hex. For example, -z max-page-size, -z stack-size, --image-base (PE) take a (default) decimal value. These options also don't seem to have a way to specify decimal or octal. That makes them inconsistent with all other ld options that take a value. -- 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/13521] ld.gold prefers unversioned symbol over default version
https://sourceware.org/bugzilla/show_bug.cgi?id=13521 Cary Coutant changed: What|Removed |Added Depends on||18703 Assignee|ian at airs dot com|ccoutant at gmail dot com --- Comment #6 from Cary Coutant --- Have you tried this with a gold built from HEAD? I think that the patches for PR 18703 also fix this bug. Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=18703 [Bug 18703] Symbol version and Version script incompatibility with 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/18703] Symbol version and Version script incompatibility with BFD ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18703 Cary Coutant changed: What|Removed |Added Blocks||13521 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=13521 [Bug 13521] ld.gold prefers unversioned symbol over default version -- 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/18703] Symbol version and Version script incompatibility with BFD ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18703 Cary Coutant changed: What|Removed |Added Blocks||12261 Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=12261 [Bug 12261] gold fails to link symbols explicitly defined in base-version -- 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/12261] gold fails to link symbols explicitly defined in base-version
https://sourceware.org/bugzilla/show_bug.cgi?id=12261 Cary Coutant changed: What|Removed |Added Status|NEW |WAITING CC||ccoutant at gmail dot com Depends on||18703 Assignee|ian at airs dot com|ccoutant at gmail dot com --- Comment #10 from Cary Coutant --- Fixed by PR 18703. Gold will accept the base version definition, but the issue Ian raised with glibc is still open. Referenced Bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=18703 [Bug 18703] Symbol version and Version script incompatibility with 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/18886] Unnecessary PLT entry for IFUNC function from DSO
https://sourceware.org/bugzilla/show_bug.cgi?id=18886 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ccoutant at gmail dot com |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/18930] internal error in sized_write_symbol, at symtab.cc:3133
https://sourceware.org/bugzilla/show_bug.cgi?id=18930 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Cary Coutant --- Fixed on master. -- 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/13521] ld.gold prefers unversioned symbol over default version
https://sourceware.org/bugzilla/show_bug.cgi?id=13521 --- Comment #8 from Cary Coutant --- > Dynamic linking is OK - but the symtab from gold doesn't have any symbol > versions even on glibc symbols, so it is a different thing. > > I think this bug can be closed, thanks That's correct -- gold does not write symbol versions to the .symtab symbol table, but it never has, and it shouldn't be necessary. -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/18703] Symbol version and Version script incompatibility with BFD ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18703 Cary Coutant changed: What|Removed |Added CC||jrnieder at gmail dot com --- Comment #23 from Cary Coutant --- *** Bug 13521 has been marked as a duplicate of 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 gold/13521] ld.gold prefers unversioned symbol over default version
https://sourceware.org/bugzilla/show_bug.cgi?id=13521 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Cary Coutant --- Closing. *** This bug has been marked as a duplicate of bug 18703 *** -- 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/18959] gold doesn't respect alignment of .rodata.str.* section
https://sourceware.org/bugzilla/show_bug.cgi?id=18959 --- Comment #2 from Cary Coutant --- > How about this patch? Seems to fix the issue on s390. However, the empty > string > seems to have been special-cased on purpose and I'm afraid it could mess > something up. I don't really know why the empty string was special-cased there; it probably shouldn't have been (the reasoning may have been that an empty string doesn't need to be aligned, but you have a good example why that's not true). This patch is small enough that I don't think I need to worry about your copyright assignment. I'll take a closer look and commit it for you if everything looks OK. Do you have write access to the binutils repo? Anyway, thanks for the fix! -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/18935] Gold assert fail when moving dot in NOLOAD section.
https://sourceware.org/bugzilla/show_bug.cgi?id=18935
--- Comment #2 from Cary Coutant ---
> Seems a bit unclear what the expected behavior is.
>
> .init_stack (NOLOAD) :
> {
>. = . + 0x200;
> } :ph_load
> With this ld.bfd creates a NOBITS SHF_ALLOC section(just like .bss).
>
> When a new non-SHF_ALLOC output section is created the address is set to 0.
> Layout::make_output_section_for_script(), which is the function that creates
> the init_stack section, only tries to create sections with SHT_PROGBITS
> section. This is why the assert fails when
> Output_section_definition::set_section_addresses() tries to assign an address
> to the section.
This script looks like it's trying to create an unloadable section,
then allocate it to a loadable segment. If all the script is trying to
do is create a loadable NOBITS section, the NOLOAD attribute shouldn't
be necessary (or allowed). The fact that it contains nothing but
uninitialized space should be sufficient. I don't think gold does the
right thing in that case, but that ought to be the bug, not that
NOLOAD should make it work.
What does Gnu ld do if you omit NOLOAD? Do you have any history that
explains why NOLOAD was added to the script?
-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/14187] gold incorrectly requires hexadecimals to start with 0x with -Ttext/-Tdata/-Tbss
https://sourceware.org/bugzilla/show_bug.cgi?id=14187 --- Comment #14 from Cary Coutant --- (In reply to Stas Sergeev from comment #13) > (In reply to Cary Coutant from comment #11) > > Created attachment 8557 [details] > > Patch to fix gold to parse -Ttext, etc., options as hex numbers > > The attached patch changes gold to parse the -Ttext, etc., values > > as hex numbers, but will print a warning if it sees a value that > > looks more like a decimal number (in order to catch legacy uses). > Please don't. > -Ttext in gold means entirely different thing, 0x won't help. > Don't break you current users without fixing anything at all. I don't see why we should leave this bug unfixed just because we don't match Gnu ld's behavior for -Ttext. The original report was about accepting hex numbers without the 0x, and had nothing to do with what you're talking about. Ian has already explained why Gnu ld's -Ttext is useless on ELF targets, and I did a little historical research to find that the -Ttext option on several other linkers is described it as setting the address of the text *segment*, which is what gold implements. I think if there's anyone out there using -Ttext with a decimal value, the proposed patch will probably catch it and warn them of the change, assuming a high likelihood that they're using a multiple of a power of two. It's probably more likely that everyone is already spelling it with a 0x. -- 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/18935] Gold assert fail when moving dot in NOLOAD section.
https://sourceware.org/bugzilla/show_bug.cgi?id=18935 --- Comment #4 from Cary Coutant --- > This script looks like it's trying to create an unloadable section, > then allocate it to a loadable segment. If all the script is trying to > do is create a loadable NOBITS section, the NOLOAD attribute shouldn't > be necessary (or allowed). The fact that it contains nothing but > uninitialized space should be sufficient. I don't think gold does the > right thing in that case, but that ought to be the bug, not that > NOLOAD should make it work. That GOLD makes BSS sections take up space in the output file is PR 16711. -- 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/18975] gold: code_fill not executed if linker script is in use
https://sourceware.org/bugzilla/show_bug.cgi?id=18975
--- Comment #1 from Cary Coutant ---
The way to fill holes in a section when using scripts is to specify a fill
pattern; e.g.:
SECTIONS {
.text : { *(.text) } = 0x90909090
}
or
SECTIONS {
.text : { FILL(0x90909090) *(.text) }
}
Interestingly, when using the latter, Gnu ld doesn't use the fill pattern, but
instead fills with a span-dependent NOP, as if no fill pattern had been
specified.
(Note: while Gnu ld supports fill patterns of arbitrary length, gold currently
supports only 4-byte fill patterns. There's a FIXME in the code, but I don't
think there's been a PR filed for that.)
Nothing in the ld manual says that a code section should be filled with NOPs in
the absence of a FILL pattern.
(Aside: If I remember the s360 instruction set well enough, instructions can be
2, 4, or 6 bytes long. Setting an alignment of 4 on a code section seems like a
bad idea to begin with. Besides that, .init and .fini sections have been
obsolete for, what, 17 years now?)
--
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/19042] unsupported reloc 311/312
https://sourceware.org/bugzilla/show_bug.cgi?id=19042 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ccoutant at gmail dot com |shenhan at google 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/19041] unsupported TLSLE reloc 549/551
https://sourceware.org/bugzilla/show_bug.cgi?id=19041 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ccoutant at gmail dot com |shenhan at google 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/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19019 Cary Coutant changed: What|Removed |Added CC||davem at davemloft dot net --- Comment #13 from Cary Coutant --- I'm having trouble understanding what an STT_SPARC_REGISTER symbol is supposed to be processed. There's nothing in the SPARC Processor Supplement (Third Edition), dated 1996, that mentions STT_SPARC_REGISTER. I found a SPARC Compliance Definition (SCD 2.4), dated 1998, that mentions it, but it's under an "Experimental" heading. It says that the symbol should be SHN_ABS if the module initializes the register, and SHN_UNDEF otherwise. I presume that an UNDEF REGISTER symbol needs to have the st_value preserved when linking, but that's not clear from the SCD, and it's also not clear whether symbols with the same st_value field (i.e., register number) should be bound together. Should two SHN_ABS REGISTER symbols with the same number produce an error? Currently, the only thing gold does with STT_SPARC_REGISTER is suppress an undefined symbol warning, with the following comment: // XXX Really need to support this better... if (sym->type() == elfcpp::STT_SPARC_REGISTER) return 1; If my presumptions are close, it sounds like we'll need a new target hook, because most of this special treatment is probably going to need to be in the non-target-specific parts of gold. Can someone point me to an up-to-date version of the SPARC psABI? -- 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/18855] String constants mixed up when linked with gold on Linux/sparc64
https://sourceware.org/bugzilla/show_bug.cgi?id=18855 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Cary Coutant --- Fixed on trunk. -- 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/18855] String constants mixed up when linked with gold on Linux/sparc64
https://sourceware.org/bugzilla/show_bug.cgi?id=18855 --- Comment #8 from Cary Coutant --- > I made a automatic test case for it (see attachment). I think the ltrans.*.s > file in my archive are my own gcc invocation on sparc64, but the files from > attachment 8619 [details] should do as well. Just run make from the attached > archive, after extracting it into a binutils build tree: Thanks for the reproducer -- that helped a lot! -- 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/19118] Gold doesn't support EM_IAMCU
https://sourceware.org/bugzilla/show_bug.cgi?id=19118 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ccoutant at gmail dot com |hjl.tools at gmail dot com Severity|normal |enhancement -- 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/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19019 --- Comment #18 from Cary Coutant --- Yes, I'm working on it. I think it's going to need some additional work in non-target-specific code to support this feature. -cary On Mon, Oct 12, 2015 at 3:10 AM, jose.marchesi at oracle dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=19019 > > --- Comment #17 from Jose E. Marchesi --- > Cary, are you still working on this issue? Otherwise I will jump in and try > to > hack the needed support in gold... > > -- > You are receiving this mail because: > You are the assignee for the 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 gold/19119] Gold accepts bogus target emulation
https://sourceware.org/bugzilla/show_bug.cgi?id=19119 --- Comment #2 from Cary Coutant --- Yes, gold uses the target of the first object file; only if there are no object files does it use the -m option (note that the option is marked "obsolete"). -cary On Wed, Oct 14, 2015 at 7:39 AM, hjl.tools at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=19119 > > --- Comment #1 from H.J. Lu --- > [hjl@gnu-6 pr19119]$ cat x.s > .text > .type _start,"function" > .global _start > _start: > ret > [hjl@gnu-6 pr19119]$ make > ./as --32 -o x.o x.s > ./ld -m elf_iamcu -o x x.o > [hjl@gnu-6 pr19119]$ file x > x: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically > linked, > not stripped > [hjl@gnu-6 pr19119]$ ld -m elf_iamcu -o x x.o > ld: i386 architecture of input file `x.o' is incompatible with iamcu output > [hjl@gnu-6 pr19119]$ > > Gold simply ignores -m elf_iamcu. > > -- > You are receiving this mail because: > You are the assignee for the 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 gold/19140] __star_* and __stop_* symbols show up in dynamic relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=19140 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Cary Coutant --- Gold creates the __start_SECTION and __stop_SECTION symbols as section-relative (non-absolute) symbols with default visibility. As such, they are pre-emptible, and we will create a dynamic relocation for any reference to them. The error message appears when trying to create a 32-bit pc-relative dynamic relocation to a pre-emptible symbol, which may indeed overflow at runtime. The absolute reference links cleanly, and we create a RELATIVE dynamic relocation for it. Declaring the __start_SECTION or __stop_SECTION symbol with hidden visibility alters this behavior, and gold will bind the pc-relative reference at link time, and will not create a dynamic relocation for it. Likewise, linking with -pie instead of -shared eliminates the dynamic relocations for the pc-relative references. Gold creates the __init_array_start symbol (and others like it) with hidden visibility. If there is a .init_array section, the symbol is a section-relative (non-absolute) symbol; a pc-relative reference to it does not need a dynamic relocation, and an absolute reference generates a RELATIVE dynamic relocation. If there is no .init_array section, gold generates an absolute symbol with value 0; a pc-relative reference will try to generate a dynamic relocation, and an absolute reference will bind at link time. I believe this is all working as intended. The Gnu linker, in my experiments: (a) Generates the PC32 dynamic relocation with no warning. (b) Generates __start_SECTION and __stop_SECTION symbols with local scope, so they are not pre-emptible. (c) Does not generate __init_array_start (et al.) in a -shared link. (They are output as undefined symbols if referenced.) I can see an argument for generating the __start_SECTION and __stop_SECTION symbols with hidden visibility, but I also see value in leaving them global. Please reopen this PR if you think we should make that 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 #3 from Cary Coutant --- (In reply to Rafael Ávila de Espíndola from comment #1) > 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. It works in my experiments. -- 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 #4 from Cary Coutant --- (In reply to Cary Coutant from comment #3) > (In reply to Rafael Ávila de Espíndola from comment #1) > > 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. > > 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. -- 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 #6 from Cary Coutant --- >> 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. I don't think so -- the relocation refers to a local symbol, so it should relocate to the right address either way. -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
