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

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-24
 CC||amodra at gmail dot com
 Ever confirmed|0   |1

--- Comment #2 from Alan Modra  ---
Thousands of files are handled fine by the linker when plugins aren't involved.
 See bfd/cache.c.  This comment from bfd/plugin.c explains why there is a
problem when using plugins:

  /* The plugin API expects that the file descriptor won't be closed
 and reused as done by the bfd file cache.  So open it again.
 dup isn't good enough.  plugin IO uses lseek/read while BFD uses
 fseek/fread.  It isn't wise to mix the unistd and stdio calls on
 the same underlying file descriptor.  */

Until the gcc plugin API is fixed there isn't much the linker can do about
running out of file descriptors.

-- 
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/23839] ld generates a corrupted relocation table for .ARM.exidx sections

[lorisnardo at live dot it]

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

lorisnardo at live dot it changed:

   What|Removed |Added

 CC||lorisnardo at live dot it

--- Comment #5 from lorisnardo at live dot it ---
Created attachment 11861
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11861&action=edit
Example of relocation outside the section

-- 
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/23839] ld generates a corrupted relocation table for .ARM.exidx sections

[lorisnardo at live dot it]

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

--- Comment #6 from lorisnardo at live dot it ---
Comment on attachment 11861
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11861
Example of relocation outside the section

In this zip there are two object files (main.o and crtbegin.o) which have been
linked using the following command:
ld --cref --verbose -d -nostdlib -EL -marmelf -o output.o -r -T lnk.cmd boot.o
main.o crtbegin.o

The linker version used is 2.28.0.20170620 which is part of the GNU Tools for
ARM Embedded Processors 6-2017-q2-update.

In the output.o object file, the last relocation in .rel.ARM.exidx, is outside
the ARM.exidx section which is referenced

-- 
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] BFD ld does not set VER_FLG_WEAK on version reference if all symbols are weak

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

Summary|Unresolved weak dependency  |BFD ld does not set
   |on a versioned symbol   |VER_FLG_WEAK on version
   |should not prevent a|reference if all symbols
   |program from running|are weak

-- 
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] BFD ld does not set VER_FLG_WEAK on version reference if all symbols are weak

[carlos at redhat dot com]

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

--- Comment #13 from Carlos O'Donell  ---
(In reply to Florian Weimer from comment #12)
>  says this:
> 
>   vna_flags
>Bitmask of flags.  Currently the following are defined:
> 
>  VER_FLG_WEAK the reference to this version is weak.

This specification was written and implemented before the glibc community
corrected their interpretation of the ELF standard and introduced
LD_DYNAMIC_WEAK to undo similar weak-style changes. That is to say that the
VER_FLG_WEAK description in "symbol-vresioning" is based on an incorrect
interpretation of the ELF standard. It was based on the idea that you would
scan all loaded shared objects for a potentially strong definition that
overrode the weak one, and you can see this means lazy loading would be useless
in this case because even one weak symbol means you need to load *everything*
to confirm no strong symbols override.

See "Weak symbols that aren't"
https://lists.x.org/archives/xorg/2006-August/017341.html
https://sourceware.org/ml/libc-hacker/2000-06/msg00029.html

Weak Symbol - Limitations
https://en.wikipedia.org/wiki/Weak_symbol#Limitations

Thus the only use left for VER_FLG_WEAK is the usage as described in the
Solaris documentation.

> 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).

It is because it is a historical implementation. We could deprecate
LD_DYANMIC_WEAK and remove lots of code and simplify things.

> 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. 

Correct, and if we wanted we could implement the Solaris meaning of
VER_FLG_WEAK for "weak version definitions." I don't know how we would instruct
a binding between the binary and the "weak version definition", some new linker
file construct like Solaris has.

> Therefore, the problem that weak symbol references
> try to solve in Ulrich's approach does not actually arise on Solaris. 

Correct, because weak *symbol* references don't exist in Solaris, only
references to versions, and those version definitions can be weak.

I think the original "symbol-versioning" design simply tried to carry the
static linker semantics of weak symbol version processing to the dynamic linker
without consideration for the impact it would have on lazy binding. Namely that
if you have an undefined weak reference to a symbol, you have to search every
object looking for a potential strong reference, instead of stopping at the
first definition (weak or strong) that you find based on search order.

> 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.)

I don't follow what you're trying to state here. Can you expand on this with an
exmaple 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 ld/24709] [arm] linker crash and assertion failure with CMSE

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
When using 0x0040 as section start address, we generate this:
0040 :
  40:   e97f e97f   sg
  44:   f408 b8b2   b.w 816c <__acle_se_foo>

[...]

816c <__acle_se_foo>:
816c:   b480push{r7}
816e:   b083sub sp, #12
[...]

If we use 0x2040 instead, the CMSE stub is located too far away from
__acle_se_foo (still at 0x816c), and we fail when trying to insert a far-call
stub.

The failing assertion is in elf32_arm_get_stub_entry:
  BFD_ASSERT (input_section->id <= htab->top_id);
in this case we have htab->top_id==478 and input_section_id==509 (input_section
is .gnu.sgstubs.__stub)

Can we iterate and mix different types of stubs insertion?

Alternatively, we could add a new type of stub "far-CMSE-stub" to deal with the
case where the CMSE stub is too far from its destination.

-- 
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] BFD ld does not set VER_FLG_WEAK on version reference if all symbols are weak

[fweimer at redhat dot com]

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

--- Comment #14 from Florian Weimer  ---
(In reply to Carlos O'Donell from comment #13)
> (In reply to Florian Weimer from comment #12)
> >  says this:
> > 
> >   vna_flags
> >Bitmask of flags.  Currently the following are defined:
> > 
> >  VER_FLG_WEAK   the reference to this version is weak.
> 
> This specification was written and implemented before the glibc community
> corrected their interpretation of the ELF standard and introduced
> LD_DYNAMIC_WEAK to undo similar weak-style changes. That is to say that the
> VER_FLG_WEAK description in "symbol-vresioning" is based on an incorrect
> interpretation of the ELF standard. It was based on the idea that you would
> scan all loaded shared objects for a potentially strong definition that
> overrode the weak one, and you can see this means lazy loading would be
> useless in this case because even one weak symbol means you need to load
> *everything* to confirm no strong symbols override.

Wasn't that disagreement about weak *definitions*?

For weak references, we still have a long-standing ambiguity if the link editor
encounters both weak and non-weak references.

I don't think any of this matters at the versioning level because the version
reference would be weak if all references are weak.  This means that
limitations due to relocation types available for a particular architectures
etc. do not come into play (which impact what you can implement with the actual
symbol bindings).

> > 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).
> 
> It is because it is a historical implementation. We could deprecate
> LD_DYANMIC_WEAK and remove lots of code and simplify things.

I think it's totally unrelated.  LD_DYANMIC_WEAK only affects weak definitions
in shared objects.  The example does not contain a weak definition.

> > 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. 
> 
> Correct, and if we wanted we could implement the Solaris meaning of
> VER_FLG_WEAK for "weak version definitions." I don't know how we would
> instruct a binding between the binary and the "weak version definition",
> some new linker file construct like Solaris has.

We have the SHT_GNU_verneed section referenced from the dynamic segment.  The
glibc loader processes that, in much the same way as the Solaris loader does
with their data structure.  The key difference is that our link editor puts
only symbol version references there for symbols which are actually referenced
by the link.

Without that, you would be able to run glibc 2.30 binaries only on systems
having glibc 2.30 or later, for example.

> I think the original "symbol-versioning" design simply tried to carry the
> static linker semantics of weak symbol version processing to the dynamic
> linker without consideration for the impact it would have on lazy binding.
> Namely that if you have an undefined weak reference to a symbol, you have to
> search every object looking for a potential strong reference, instead of
> stopping at the first definition (weak or strong) that you find based on
> search order.

You always have to search all objects for an undefined weak symbol.  There is
no defined symbol at which the search can stop.

> > 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.)
> 
> I don't follow what you're trying to state here. Can you expand on this with
> an exmaple please?

Solaris has a capability to specify the symbol versions you want to require
from a specific soname.  See “Specifying a Version Binding” in the
documentation you cited, and in particular “If a shared object has been
versioned over several software releases, application developers can restrict
themselves to the interfaces that were available in a previous software
release. Thus, an application can be built using the latest release of the
shared object in the knowledge that the application's interface requirements
can be met by a previous release of the shared object.”.  Since individual
symbols do not

[Bug ld/24721] -Map generates corrupt .note.gnu.property section

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
The fix has been posted at

https://sourceware.org/ml/binutils/2019-06/msg00190.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 ld/24721] -Map generates corrupt .note.gnu.property section

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by H.J. Lu :

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

commit f93ab3a0b8039a1667a666f013cca50b03d67f9b
Author: H.J. Lu 
Date:   Mon Jun 24 11:08:40 2019 -0700

elf: Remove the property after reporting its removal

commit d2ef37ebd9f771d06edf1fdea37970f60b242b2d
Author: H.J. Lu 
Date:   Fri Dec 7 08:30:30 2018 -0800

elf: Report property change when merging properties

failed to remove the property after reporting it has been removed.  This
patch corrects it.

bfd/

PR ld/24721
* elf-properties.c (elf_merge_gnu_property_list): Remove the
property after reporting property removal.

ld/

PR ld/24721
* testsuite/ld-x86-64/x86-64.exp: Run PR ld/24721 tests.
* testsuite/ld-x86-64/pr24721-x32.d: New file.
* testsuite/ld-x86-64/pr24721.d: Likewise.
* testsuite/ld-x86-64/pr24721.map: Likewise.
* testsuite/ld-x86-64/pr24721a.s: Likewise.
* testsuite/ld-x86-64/pr24721b.s: Likewise.

-- 
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/24721] -Map generates corrupt .note.gnu.property section

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_32-branch branch has been updated by H.J. Lu
:

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

commit df010caac3b33b1d38b6d67024091854c3f77c77
Author: H.J. Lu 
Date:   Mon Jun 24 11:08:40 2019 -0700

elf: Remove the property after reporting its removal

commit d2ef37ebd9f771d06edf1fdea37970f60b242b2d
Author: H.J. Lu 
Date:   Fri Dec 7 08:30:30 2018 -0800

elf: Report property change when merging properties

failed to remove the property after reporting it has been removed.  This
patch corrects it.

bfd/

PR ld/24721
* elf-properties.c (elf_merge_gnu_property_list): Remove the
property after reporting property removal.

ld/

PR ld/24721
* testsuite/ld-x86-64/x86-64.exp: Run PR ld/24721 tests.
* testsuite/ld-x86-64/pr24721-x32.d: New file.
* testsuite/ld-x86-64/pr24721.d: Likewise.
* testsuite/ld-x86-64/pr24721.map: Likewise.
* testsuite/ld-x86-64/pr24721a.s: Likewise.
* testsuite/ld-x86-64/pr24721b.s: Likewise.

(cherry picked from commit f93ab3a0b8039a1667a666f013cca50b03d67f9b)

-- 
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/24721] -Map generates corrupt .note.gnu.property section

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed for 2.33 and 2.32 branch.

-- 
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] BFD ld does not set VER_FLG_WEAK on version reference if all symbols are weak

[carlos at redhat dot com]

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

--- Comment #15 from Carlos O'Donell  ---
(In reply to Florian Weimer from comment #14)
> (In reply to Carlos O'Donell from comment #13)
> > (In reply to Florian Weimer from comment #12)
> > >  says this:
> > > 
> > >   vna_flags
> > >Bitmask of flags.  Currently the following are defined:
> > > 
> > >  VER_FLG_WEAK the reference to this version is weak.
> > 
> > This specification was written and implemented before the glibc community
> > corrected their interpretation of the ELF standard and introduced
> > LD_DYNAMIC_WEAK to undo similar weak-style changes. That is to say that the
> > VER_FLG_WEAK description in "symbol-vresioning" is based on an incorrect
> > interpretation of the ELF standard. It was based on the idea that you would
> > scan all loaded shared objects for a potentially strong definition that
> > overrode the weak one, and you can see this means lazy loading would be
> > useless in this case because even one weak symbol means you need to load
> > *everything* to confirm no strong symbols override.
> 
> Wasn't that disagreement about weak *definitions*?

I think we talked past eachother here. Thank you for responding to my other
points. I am going to try and stay on point here for this issue. We should
discuss semantics of dynamic bindings on libc-alpha, sorry for going off topic
earlier.

I raised the issue of LD_DYNAMIC_WEAK only as an instructive reference that
discussions about weak symbols in dynamic binding are not correct.

Both weak version symbol references and weak version symbol definitions should
not be used when discussing dynamic binding.

In this particular bug, in this particular example, you have an undefined
reference to foo being bound to a non-weak version definition of foo in
foo-link2.so. The weak attribute in the source C file only tells the linker to
create a new symbol named foo if one doesn't already exist and mark it weak.
The static linker does the actual binding from the executable to foo-link2.so,
and the version symbol definition is non-weak.

The only time VER_FLG_WEAK should be set in vernaux vna_flags is to indicate
that the original binding was against a weak version definition. Something
which doesn't happen in this example. Even if we adjust the sources to make it
happen, binutils doesn't record it as a being weak. So the first bug is that
weak version symbol definitions don't mark the version definition as
VER_FLG_WEAK.

I can inject the flag:

Version definition section '.gnu.version_d' contains 2 entries:
  Addr: 0x03e8  Offset: 0x0003e8  Link: 4 (.dynstr)
  00: Rev: 1  Flags: BASE  Index: 1  Cnt: 1  Name: ./foo-run.so
  0x001c: Rev: 1  Flags: WEAK  Index: 2  Cnt: 1  Name: FOO_1

And *then* we get the correct WEAK version reference:

Version needs section '.gnu.version_r' contains 2 entries:
 Addr: 0x00400428  Offset: 0x000428  Link: 6 (.dynstr)
  00: Version: 1  File: ./foo-run.so  Cnt: 1
  0x0010:   Name: FOO_1  Flags: WEAK  Version: 3
  0x0020: Version: 1  File: libc.so.6  Cnt: 1
  0x0030:   Name: GLIBC_2.2.5  Flags: none  Version: 2

but we still fail:

./a.out2
./a.out2: ./foo-run.so: no version information available (required by ./a.out2)
./a.out2: relocation error: ./a.out2: symbol foo version FOO_1 not defined in
file ./foo-run.so with link time reference

So we have a recorded binding in the binary saying that originally we were
bound to a weak version definition.

The enhancement we can make to binutils and glibc is to do exactly as Solaris
does, which is to ignore any reference to a weak version declaration, and we
know this is the case because the version reference is weak which indicates it
was bound at static link time to a weak version definition.

The language in "symbol-versioning", particularly this language:
~~~
There is one situation where a missing symbol definition is not an
error.  This is when the vna_flags in the Elfxx_Vernaux entry has the
VER_FLG_WEAK bit set.  In this case only a warning is issued and the
object is used normally.
~~~
I believe this is trying to set out the same semantics as in Solaris. At
runtime when you use a slightly older version of the library without the
optional performance fix, you want to still be able to run but perhaps do
something different.

Therefore I think the ask is for glibc *and* binutils to do this:

- Implement Solaris weak version definition handling:
  - Binutils to record in .gnu.version_d that if all symbol definitions are
weak then the version is WEAK.
  - glibc to avoid issuing an error if VER_FLG_WEAK is set on a version
reference because it indicates that
the original static linkage was against a weak version definition and it
should be ignored at runtime.

The subject should be flipped the other way around I think:

"BFD ld does not set VER_FLG_WEAK on version definition if all symbols are
weak."

> For weak references, we still hav

[Bug gold/17556] crashing when mixing SHF_ALLOC and non SHF_ALLOC sections

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
A patch is posted at

https://sourceware.org/ml/binutils/2019-06/msg00193.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 binutils/24719] objdump fails to reject invalid scatter/gather prefetch instructions

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-24
   Assignee|unassigned at sourceware dot org   |hjl.tools at gmail dot 
com
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Created attachment 11863
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11863&action=edit
Please try this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/24685] [RISCV] R_RISCV_CALL_PLT should not create a canonical PLT in -no-pie mode

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-25
 CC||wilson at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jim Wilson  ---
Looks like the problem is in riscv_elf_finish_dynamic_symbol where we have
  /* If the symbol is weak, we do need to clear the value.  
 Otherwise, the PLT entry would provide a definition for
 the symbol even if the symbol wasn't defined anywhere, 
 and so the symbol would never be NULL.  */
  if (!h->ref_regular_nonweak)
sym->st_value = 0;

The well maintained targets all have check for !h->pointer_equality_needed in
addition to or instead of the !h->ref_regular_nonweak check.  It looks like
this pointer_equality_needed check is missing from a lot of ports, but maybe
not all of them support linux shared libraries.

So we need code to set h->pointer_equality_needed correctly based on relocs
seen, and then a simple check to clear sym->st_value if pointer_equality_needed
is zero.

-- 
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