[Bug ld/24689] string table corruption

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24689

--- Comment #5 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Alan Modra :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=14b2a8e4244a29208ad430167860a0f01b20f215

commit 14b2a8e4244a29208ad430167860a0f01b20f215
Author: Alan Modra 
Date:   Sun Jun 23 12:10:02 2019 +0930

PR24689 again, string table corruption

Depending on optimisation level and gcc version, git commit 890f750a3b
introduces a false positive warning that i_shdrp may be used
uninitialized.

PR 24689
* elfcode.h (elf_object_p): Warning 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 ld/24704] [2.33 Regression] Internal error building skiboot for powerpc64-linux-gnu

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24704

--- Comment #3 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Alan Modra :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bb22a41815facfaa3de621aad5d055eb8e477082

commit bb22a41815facfaa3de621aad5d055eb8e477082
Author: Alan Modra 
Date:   Sun Jun 23 12:28:39 2019 +0930

PR24704, Internal error building skiboot for powerpc64-linux-gnu

While the skiboot linker script bears some culpability in this PR,
it's also true that the GOT indirect to GOT relative optimisation for
16-bit offsets isn't safe.  At least, it isn't safe to remove the GOT
entry based on distance between the GOT pointer and symbol calculated
from the preliminary layout.  So this patch removes that optimisation,
and reduces the range allowed for 32-bit and 34-bit offsets.

PR 24704
bfd/
* elf64-ppc.c (R_PPC64_GOT16_DS): Don't set has_gotrel.
(ppc64_elf_edit_toc): Don't remove R_PPC64_GOT16_DS got entries.
Reduce range of offsets allowed for other GOT relocs.
ld/
* testsuite/ld-powerpc/elfv2exe.d: Update.
* testsuite/ld-powerpc/elfv2so.d: Update.

-- 
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/24723] New: Linker fails with "too many open files"

[benjamin.redelings at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24723

Bug ID: 24723
   Summary: Linker fails with "too many open files"
   Product: binutils
   Version: 2.32
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: benjamin.redelings at gmail dot com
  Target Milestone: ---

When trying to link a large program, the linker fails with "Too many open
files".
This occurs with binutils 2.32, so the previous similar bugreport with 2.31 may
not apply (#23573).

/usr/bin/x86_64-w64-mingw32-g++  -o rb.exe
'rb@exe/src_revlanguage_main.cpp.obj' -L/home/bredelings/win_root/mingw64/lib
-Wl,-O1 -Wl,--start-group librb-core.a librb-revlanguage.a librb-lib.a
-lboost_regex-mt -lboost_program_options-mt -lboost_thread-mt -lboost_system-mt
-lboost_filesystem-mt -lboost_date_time-mt -lboost_serialization-mt -pthread
-mconsole -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32
-luuid -lcomdlg32 -ladvapi32 -Wl,--end-group
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lstdc++
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lmingw32
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lgcc_s
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lgcc
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lmoldname
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lmingwex
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lmsvcrt
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lpthread
/usr/bin/x86_64-w64-mingw32-ld: cannot find -ladvapi32
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lshell32
/usr/bin/x86_64-w64-mingw32-ld: cannot find -luser32
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lkernel32
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lmingw32
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lgcc_s
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lgcc
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lmoldname
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lmingwex
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lmsvcrt
/usr/bin/x86_64-w64-mingw32-ld: cannot find
/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/crtend.o: Too many open files
collect2: error: ld returned 1 exit status

Versions look like this:

$ uname -a
Linux name 5.0.0-trunk-amd64 #1 SMP Debian 5.0.2-1~exp1 (2019-03-18) x86_64
GNU/Linux

$ /usr/bin/x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr
--includedir='/usr/include' --mandir='/usr/share/man'
--infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu'
--libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode
--disable-dependency-tracking --prefix=/usr --enable-shared --enable-static
--disable-multilib --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes
--with-tune=generic --with-headers=/usr/x86_64-w64-mingw32/include
--enable-version-specific-runtime-libs --enable-fully-dynamic-string
--enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto
--enable-threads=win32 --program-suffix=-win32
--program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32
--with-as=/usr/bin/x86_64-w64-mingw32-as
--with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic
--enable-libstdcxx-filesystem-ts=yes
Thread model: win32
gcc version 8.3-win32 20190428 (GCC) 

$ /usr/bin/x86_64-w64-mingw32-ld --version
GNU ld (GNU Binutils) 2.32
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

The ld command-line that is failing looks like this:
/usr/bin/x86_64-w64-mingw32-ld -plugin
/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccXUMZS3.res -plugin-opt=-pass-through=-lmingw32
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex
-plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lpthread
-plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32
-plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -m
i386pep --subsystem console -Bdynamic -o rb.exe
/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/../../../../x86_64-w64-mingw32/lib/crt2.o
/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/crtbegin.o
-L/home/bredelings/win_root/mingw64/lib
-

[Bug ld/24723] Linker fails with "too many open files"

[benjamin.redelings at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24723

--- Comment #1 from Benjamin Redelings  ---
Created attachment 11860
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11860&action=edit
An strace log of the linker running out of open 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 ld/24704] [2.33 Regression] Internal error building skiboot for powerpc64-linux-gnu

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24704

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |2.33

--- Comment #4 from Alan Modra  ---
Fixed.

-- 
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/24718] Unresolved weak dependency on a versioned symbol should not prevent a program from running

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24718

--- Comment #9 from Carlos O'Donell  ---
(In reply to Paul Pluzhnikov from comment #8)
> (In reply to Florian Weimer from comment #6)
> 
> > I would say this is a static link editor limitation.  It has to mark symbol
> > versions as weak if they are only referenced by weak symbols.
> 
> Ok, I'll update product to "binutils".

Again, I'll comment for the record that the "weak" status of the symbol should
make no difference at runtime.

Please also note that VER_FLG_WEAK was not for weak symbols, but for "weak
version definitions" :
https://docs.oracle.com/cd/E19957-01/806-0641/6j9vuqujg/index.html#chapter5-16371

That is to say:
* If you have a bug fix / performance improvement, which is externally
invisible to the binary, you can expose a weak version definition for the bug
fix e.g. GLIBC_BZ24718.
* Normal binaries record the weak version definition, but if it's not present
at runtime they operate normally, and the lack of this weak version definition
is ignored.
* Binaries that need the bug fix can depend explicitly on the weak version
definition which promotes it to a strong version definition and it becomes
_required_ at runtime.

In summary:
- weak symbols are not relevant to dynamic linking.
- VER_FLG_WEAK is not for weak symbols but for weak version definitions, and
the traditional role for those in Solaris is to demarcate bug fixes and
performance changes or other library internal changes. Using it for optional
"weak" functions could have unintended behavioural consequences that would need
to be reviewed.

-- 
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/24718] Unresolved weak dependency on a versioned symbol should not prevent a program from running

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24718

--- Comment #10 from Carlos O'Donell  ---
(In reply to Paul Pluzhnikov from comment #8)
> (In reply to Florian Weimer from comment #6)
> 
> > I would say this is a static link editor limitation.  It has to mark symbol
> > versions as weak if they are only referenced by weak symbols.
> 
> Ok, I'll update product to "binutils".

What do you expect binutils 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 ld/24718] Unresolved weak dependency on a versioned symbol should not prevent a program from running

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24718

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #11 from Alan Modra  ---
> VER_FLG_WEAK was not for weak symbols, but for "weak version definitions"

That's my understanding too.  I was making the same comment when Carlos'
comment #9 landed.

-- 
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/24718] Unresolved weak dependency on a versioned symbol should not prevent a program from running

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24718

--- Comment #12 from Florian Weimer  ---
 says this:

  vna_flags
   Bitmask of flags.  Currently the following are defined:

 VER_FLG_WEAK   the reference to this version is weak.

I believe this is what is implemented in glibc, but it's not bean tested so far
because binutils doesn't set this flag.  It should be quite safe to introduce
this feature in binutils (obviously for GNU only).

The Solaris documentation is not helpful at all in this case because our
implementation is so very different.  Based on reading that documentation,
Solaris does not bind individual symbols to versions, only shared object
dependencies as a whole.  Therefore, the problem that weak symbol references
try to solve in Ulrich's approach does not actually arise on Solaris.  Instead,
you can just instruct the link editor to omit certain symbol version references
from the resulting binary, keep a weak (unversioned) symbol reference, and
apply a run-time check, as with any weak symbol.  Since it is not possible to
define multiple symbol versions for the same symbol name on Solaris,
restricting the set of bound symbol versions at static link time is safe.  (In
the GNU implementation, this is unsafe because different versioned symbols can
require different declarations and have different behavior in general, so
deferring this decision to the link editor does not 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