[Bug ld/31009] regression: assertion fail ../../bfd/merge.c:243

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #13 from Michael Matz  ---
So, immediate problem fixed.  That the error-paths that are supposed to recover
from out-of-memory here (and invalidly were triggered) didn't quite work in
recovery is something for another time.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31009] regression: assertion fail ../../bfd/merge.c:243

[matz at suse dot de]

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

--- Comment #10 from Michael Matz  ---
(In reply to Jonny Weir from comment #7)
> I made the following change:

Thanks!

> XXX resize 1: count=1598 added=1086327410 newnb=1048576

Gah, yeah.  So, one of the input string sections (most likely one of the
.debug_str sections) is about 2GB in size.  We overestimate this (quite much)
to add 1G strings, which ...

> XXX resize 2: newnb=2147483648

... seems to work fine, still ...


> XXX resize 1: count=755248 added=68141 newnb=0
> false1: newnb=0

... but then, when we've already allocated 2G buckets (and used 755248 of
those),
we fail to add space for another (estimated) 68141 ones.  (We fail to do so,
because we can't double the number of buckets again, as it's only a unsigned
int).  Why that leads to errors down the pipe I can't quite see yet, these
input sections which can't be added to the hash table for $reason are supposed
to be ignored and just added as is into the output.  But whatever the reason
for _that_ is doesn't matter at first.  The first thing that goes wrong
is already that we go into the resize-me case at all with these numbers.
When we have 2 billion buckets, of which 755k are used, and want to add
(potentially) another 68k, then obviously we don't need to resize anything.
The existing 2G buckets should be enough :-)

The error is in another overflow in the check:

  if (bfdtab->count + added > table->nbuckets * 2 / 3)
{
  unsigned i;
  unsigned long newnb = table->nbuckets * 2;
  ... rest of resize code ...

as table->nbuckets is 2G at entry to this, the expression table->nbuckets * 2
is going to be zero, so once nbuckets goes to 2G (the max supported size)
the above expression will always be true, we always go into the resize case,
and we always will fail it (with the followup errors then occurring).

Let's rewrite it into "/ 3 * 2" to avoid overflow in the check.  Can you test
this, please? (patch still contains the printf debugs):

diff --git a/bfd/merge.c b/bfd/merge.c
index 722e6659486..f81cd30197f 100644
--- a/bfd/merge.c
+++ b/bfd/merge.c
@@ -167,7 +167,7 @@ static bool
 sec_merge_maybe_resize (struct sec_merge_hash *table, unsigned added)
 {
   struct bfd_hash_table *bfdtab = >table;
-  if (bfdtab->count + added > table->nbuckets * 2 / 3)
+  if (bfdtab->count + added > table->nbuckets / 3 * 2)
 {
   unsigned i;
   unsigned long newnb = table->nbuckets * 2;
@@ -175,12 +175,14 @@ sec_merge_maybe_resize (struct sec_merge_hash *table,
unsigned added)
   uint64_t *newl;
   unsigned long alloc;

-  while (bfdtab->count + added > newnb * 2 / 3)
+  printf ("XXX resize 1: count=%u added=%u newnb=%lu\n", bfdtab->count,
added, newnb);
+  while (bfdtab->count + added > newnb / 3 * 2)
{
  newnb *= 2;
  if (!newnb)
return false;
}
+  printf ("XXX resize 2: newnb=%lu\n", newnb);

   alloc = newnb * sizeof (newl[0]);
   if (alloc / sizeof (newl[0]) != newnb)
@@ -240,7 +242,7 @@ sec_merge_hash_insert (struct sec_merge_hash *table,
   hashp->u.suffix = NULL;
   hashp->next = NULL;
   // We must not need resizing, otherwise _index is wrong
-  BFD_ASSERT (bfdtab->count + 1 <= table->nbuckets * 2 / 3);
+  BFD_ASSERT (bfdtab->count + 1 <= table->nbuckets / 3 * 2);
   bfdtab->count++;
   table->key_lens[_index] = (hash << 32) | (uint32_t)len;
   table->values[_index] = hashp;

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31009] regression: assertion fail ../../bfd/merge.c:243

[matz at suse dot de]

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

--- Comment #6 from Michael Matz  ---
(In reply to Jonny Weir from comment #5)
> Ignore that last message, it is misleading, this is a more accurate
> representation of what is happening with the values:

Ah, yes.  I was suspecting already that you were printing the value*2/3.
Anyway:

> bfdtab->count + 1 = 1598 | table->nbuckets = 524288 | table->nbuckets * 2 /
> 3 = 349525
> bfdtab->count + 1 = 1599 | table->nbuckets = 2147483648 | table->nbuckets *
> 2 / 3 = 0

Yeez!  One of the input sections is projected to possibly add 2 billion
strings.
Can you perhaps add some printfs to sec_merge_maybe_resize (the only place
that does increase nbuckets)?  Similar to below, maybe also add printf's for
each early-out (all the 'return false' in there).

And then we need to trace why the overflow isn't detected earlier (I tried to
make it so that it does, obviously I failed, that's what the 'return false' are
for, after all) and isn't gracefully handled.

diff --git a/bfd/merge.c b/bfd/merge.c
index 722e6659486..b36cee49b3a 100644
--- a/bfd/merge.c
+++ b/bfd/merge.c
@@ -175,12 +175,14 @@ sec_merge_maybe_resize (struct sec_merge_hash *table,
unsigned added)
   uint64_t *newl;
   unsigned long alloc;

+  printf ("XXX resize 1: count=%u added=%u newnb=%lu\n", bfdtab->count,
added, newnb);
   while (bfdtab->count + added > newnb * 2 / 3)
{
  newnb *= 2;
  if (!newnb)
return false;
}
+  printf ("XXX resize 2: newnb=%lu\n", newnb);

   alloc = newnb * sizeof (newl[0]);
   if (alloc / sizeof (newl[0]) != newnb)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31009] regression: assertion fail ../../bfd/merge.c:243

[matz at suse dot de]

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

--- Comment #2 from Michael Matz  ---
Another possible way forward: if you add '-save-temps' to the link/compile
command then the LTO phase will leave around the $foobar.ltransXXX.ltrans.o
files and the *.debug.o files, that are ultimately input to the second linker
phase (the one that throws these errors).  If you can provide access to these,
plus the other linker input files and command line (also see the output when
adding '-v', search for "collect2" and COLLECT_GCC_OPTIONS), then we could also
analyse the causes. The ltrans and .debug files will also be very large,
though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31009] regression: assertion fail ../../bfd/merge.c:243

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at suse dot de

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Michael Matz  ---
Fixed with the commit above.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)

[matz at suse dot de]

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

--- Comment #3 from Michael Matz  ---
When you move the libs into a subdir (and accordingly don't have them in the
current dir anymore!) then your "lib1.a(*)" should have given you an error,
with old ld, with new ld and with patch:

% ls -l lib* subdir/lib*
-rw-r--r-- 1 matz suse 3028 Jun 26 15:02 lib1.a.away
-rw-r--r-- 1 matz suse 1422 Jun 26 15:02 lib2.a.away
-rw-r--r-- 1 matz suse 3028 Jun 26 15:02 subdir/lib1.a
-rw-r--r-- 1 matz suse 1422 Jun 26 15:02 subdir/lib2.a
% grep lib1 linker.ld
lib1.a(*)
% ld -Map bla.map -o out.bin -T linker.ld subdir/lib1.a subdir/lib2.a
ld: cannot find lib1.a: No such file or directory

(this is with an oldish system linker, i.e. before the prefix tree change).

The thing is the following: with a bare-word filename part in the section
statement (i.e. no colons and no wildcards), the named "thing" is loaded in a
special mode: as if named on command line, but with searching in search paths.
E.g. adding '-L subdir' above would make the error message go away (but
doing that would still not make just mentioning "lib1.a" on the cmdline work).

If you name the bare-word part also on the command line, then the thing
might be loaded twice.  It's usually not, because obvious duplicates, based
on filenames are not loaded twice, but with enough work you could make ld
do that, and get e.g. duplicate symbol definitions.  As the above are archives
it's even harder, but if they are for instance normal .o files you can easily
run into that:

% ln test1.o subdir/test1.o
% egrep 'lib|test' linker.ld
test1.o(*)
test2.o(*)
% ld -Map bla.map -o out.bin -T linker.ld subdir/test1.o subdir/lib1.a
subdir/lib2.a
ld: subdir/test1.o: in function `func1':
test1.c:(.text+0x0): multiple definition of `func1';
test1.o:test1.c:(.text+0x0): first defined here

Compare with:

% egrep 'lib|test' linker.ld 
test*.o(*)
% ld -Map bla.map -o out.bin -T linker.ld subdir/test1.o subdir/lib1.a
subdir/lib2.a 
% # worked

I.e. non-bare-word parts don't actively load anything, they only match against
things that are otherwise loaded (per cmdline, INPUT statements or the above
form of bare-word pseudo-INPUT statements).

So, if your 'lib1.a(*)' statement worked also when lib1.a was in a subdir,
that was because it somehow was loaded without error, either because of
a searchpath (-L) or because a file named lib1.a was still in the current dir,
in which case that probably wasn't the intention.  If the latter then it wasn't
really matching against the subdir/lib1.a, but rather against ./lib1.a which
may or may not have been the same file.

It's all mightily confusing, I agree.  But parts of all this is historic
baggage, and parts of this is even documented (e.g. that bare-words are
loading stuff), so we can't easily remove that behaviour.

IMHO it's best to avoid bare-word section "matchers" (certainly with
archives) and just name all to-be-loaded things either on the cmdline
or in explicit INPUT statements.  Otherwise there's always the danger
to run into confusions in mildly complex directory layout situations.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

   Assignee|unassigned at sourceware dot org   |matz at suse dot de
   Last reconfirmed||2023-06-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30590] Section matching broken by prefix tree change (b1eecf6f66a4a642)

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at suse dot de

--- Comment #1 from Michael Matz  ---
The patch I posted at
  https://sourceware.org/pipermail/binutils/2023-June/128002.html
should fix this (but please test on your full example).

A note for the future: if you want to name archives in the file-part of section
globs, then the documented forms are (and I'll cite):


   You can also specify files within archives by writing a pattern
matching the archive, a colon, then the pattern matching the file, with
no whitespace around the colon.

'archive:file'
 matches file within archive
'archive:'
 matches the whole archive
':file'
 matches file but not one in an archive

   Either one or both of 'archive' and 'file' can contain shell
wildcards.


That it worked formerly with just "lib1.a(*)" is an undocumented behaviour that
got lost with my prefix-tree matching (and is reinstated with above patch).
The above forms would have worked.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30499] reword "alignment ... is smaller than alignment ..." warning

[matz at suse dot de]

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

--- Comment #9 from Michael Matz  ---
(In reply to Nick Clifton from comment #7)
> Created attachment 14923 [details]
> Proposed patch
> 
> Hi Michael,
> 
>OK, what do you think of this patch ?  It would change the wording to:
> 
> ld: warning: alignment 32 of normal symbol `com2_' in test2.o is smaller
> than 64 used by the common definition in test1.o
> ld: warning: NOTE: alignment discrepancies can cause real problems. 
> Investigation is advised.

If you think the verbosity is not a problem I have no problem with it either.
But then you could also add "(see PR30499)" somewhere to help with the advised
investigation :-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30499] reword "alignment ... is smaller than alignment ..." warning

[matz at suse dot de]

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

--- Comment #4 from Michael Matz  ---
(In reply to Nick Clifton from comment #3)
> (In reply to Michael Matz from comment #2)
> > Hmm, on reflection this proposed message might not actually be correct.
> > Generally one can't just increase the alignment of random data symbols like
> > here: they might be part of a larger object with known relative offsets, and
> > changing the alignment of such data symbol will then break such knowledge.
> 
> Can this happen ?
> 
> More to the point, if a meta-object does contain sub-objects with their own
> symbols, shouldn't the offsets of those sub-objects be computed by
> calculating
> the difference between the symbol's address and the meta-object's start
> address.  Rather than just by being pre-calculated to some fixed value ?

Sometimes yes.  But the more usual case is that the addresses are encoded as
section-relative.  Especially so if the symbols in question aren't global, but
still just so happen to be related (by positioning) to the common symbol that
is
tried to be moved around.  For instance, in this example:

% cat test1.s
  .type   com2_,@object
  .comm   com2_,8,64
  .quad   com2_
  .type   com1_,@object
  .comm   com1_,8,64
  .quad   com1_
.section .note.GNU-stack

% cat test2.s
  .globl  com2_
  .data
randomstuff:
   .quad  1
  .align 32
  .type   com1_, @object
  .size   com1_, 8
com1_:
  .quad   2
  .align 32
  .type   com2_, @object
  .size   com2_, 8
com2_:
  .quad   2
foobar:
  .quad   3
addroffoobar:
   .quad  foobar - randomstuff
.section .note.GNU-stack

main.c and compile commands as above.  Note how I now have two "problematic"
common symbols, both constrained to be 64-aligned from test1.s, but actually
only getting a 32-alignment in test2.s.  Not also that the distance between
com1_ and com2_ is basically fixated in test2.s because I encode a distance
between sourrounding (non-global) symbols.  So, as a whole this .data section
from test2.s can move happily around, but of course nothing can be added
right _into_ that blob representing test2.o:.data.  To wit:

% cc ...
ld: warning: alignment 32 of symbol `com2_' in test2.o is smaller than 64 in
test1.o

Note how it complains only about one, not both, symbols.  And further:

% readelf -sW a.out
...
15: 00404020 0 NOTYPE  LOCAL  DEFAULT   23 randomstuff
...
17: 00404068 0 NOTYPE  LOCAL  DEFAULT   23 foobar
18: 00404070 0 NOTYPE  LOCAL  DEFAULT   23 addroffoobar
...
28: 00404060 8 OBJECT  GLOBAL DEFAULT   23 com2_
...
43: 004040c0 8 OBJECT  GLOBAL DEFAULT   25 com1_

% readelf -x .data a.out
Hex dump of section '.data':
  0x00404000     
  0x00404010     
  0x00404020 0100    
  0x00404030     
  0x00404040 0200    
  0x00404050     
  0x00404060 0200  0300  
  0x00404070 4800    H...

So, it correctly left the distance between foobar and randomstuff at 0x48,
both in symbol table and .data content.  It achieved the 64-alignment of
'com1_'
by letting the begin of test2.o:.data (corresponding also to the symbol
'randomstuff') be at 0x20 within a.out:.data.  But that means that com2_ also
had to move with it, to .data+0x60.  That's _not_ 64-aligned.  And especially
it can't be made 64-aligned in any way.  Either it would break the
alignment of com1_ again, or it would change the distance between randomstuff
and foobar, which wouldn't be able to rectified as no trace of that is left
in the object files (and rightly so!).

Curiously it only gave a warning message about com2_, which is the one where
it couldn't do any alignment upgrade, but not about com1_ where it actually did
change it.

So, all in all, ultimately I think:
a) the suggested wording of the warning is wrong, as not achievable in the
   general case
b) the above example shows how the warning might even be regarded as error.
   Code that assumes 64-alignment for com1_ and com2_ (as requested by test1.o)
   _will_ break with the generated output and there's no way for the linker
   to magically make it work.

In the interest of backward compatibility and in light of the existence of
-fcommon for C, even though its default changed a couple years back, which
makes mixture of common and data symbols be somewhat common, I'm not actually
suggesting to make this an error, though.

We could give the suggested wording of the warning in the very specific case
where the target alignment is achievable.  But the current code doesn't lend
itself to that, at the place the warning is given it doesn't really know
yet if that symbol can be over-aligned or not.  (As shown above 

[Bug ld/30499] reword "alignment ... is smaller than alignment ..." warning

[matz at suse dot de]

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

--- Comment #2 from Michael Matz  ---
Hmm, on reflection this proposed message might not actually be correct.
Generally one can't just increase the alignment of random data symbols like
here: they might be part of a larger object with known relative offsets, and
changing the alignment of such data symbol will then break such knowledge.

In _this_ specific case everything works out and the resulting alignment of
'com2_' is 64.  But that might not always be possible, which I guess is the
reason for the warning in the first place.  And changing the wording to suggest
that the bigger alignment is actually used always is then misleading.

So one point for not changing the warning :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30499] reword "alignment ... is smaller than alignment ..." warning

[matz at suse dot de]

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

--- Comment #1 from Michael Matz  ---
Patch would be trivial:

--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -5339,7 +5339,7 @@ elf_link_add_object_symbols (bfd *abfd, struct
bfd_link_info *info)
_bfd_error_handler
  /* xgettext:c-format */
  (_("warning: alignment %u of symbol `%s' in %pB"
-" is smaller than %u in %pB"),
+" changed to %u to match %pB"),
   1 << normal_align, name, normal_bfd,
   1 << common_align, common_bfd);
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30499] New: reword "alignment ... is smaller than alignment ..." warning

[matz at suse dot de]

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

Bug ID: 30499
   Summary: reword "alignment ... is smaller than alignment ..."
warning
   Product: binutils
   Version: 2.41 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: matz at suse dot de
  Target Milestone: ---

A customer of a customer of ours is requesting that the warning about
mismatching symbol alignments be reworded.  Given this:

% cat test1.s
  .type   com2_,@object
  .comm   com2_,8,64
  .quad   com2_
% cat test2.s
  .globl  com2_
  .data
  .align 32
  .type   com2_, @object
  .size   com2_, 8
com2_:
  .quad   2
% cat main.c
int main () {
return 0;
}
% cc -c main.c test1.s test2.s
% cc main.o test1.o test2.o

The current warning is:
warning: alignment 32 of symbol `com2_' in test2.o is smaller than 64 in
test1.o

The proposal would be:
warning: alignment 32 of symbol `com2_' in test2.o changed to 64 to match
test1.o

I think the proposed warning is a little bit nicer as being explicit what the
resolution to the situation is.  I'm undecided if it's nicer enough to warrant
changing a translated warning, which is why I'm creating this PR, perhaps I
get opinions :-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30437] aarch64: RELA relocations don't ignore section content as they should

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Michael Matz  ---
Fixed in master.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30437] aarch64: RELA relocations don't ignore section content as they should

[matz at suse dot de]

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

--- Comment #2 from Michael Matz  ---
ld.gold gets the testcase correct:

% ld.gold -pie rela.o
% objdump -sRj .data a.out 

a.out: file format elf64-littleaarch64

DYNAMIC RELOCATION RECORDS
OFFSET   TYPE  VALUE
0002 R_AARCH64_RELATIVE  *ABS*+0x00020032
00020008 R_AARCH64_RELATIVE  *ABS*+0x00020054


Contents of section .data:
 2 32000200  54000200   2...T...

The patch does the same for ld.bfd.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30437] aarch64: RELA relocations don't ignore section content as they should

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

   Assignee|unassigned at sourceware dot org   |matz at suse dot de
 Status|NEW |ASSIGNED

--- Comment #1 from Michael Matz  ---
Created attachment 14872
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14872=edit
patch for the problem

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30437] New: aarch64: RELA relocations don't ignore section content as they should

[matz at suse dot de]

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

Bug ID: 30437
   Summary: aarch64: RELA relocations don't ignore section content
as they should
   Product: binutils
   Version: 2.41 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: matz at suse dot de
  Target Milestone: ---

The aarch64 psABI prescribes that all RELA relocs are to be idempotent. 
Amongst
other things that means they have to ignore pre-existing section content of the
to-be-relocated place.  The golang toolchain runs into this issue by failing
the
testGCData testcase as in https://github.com/golang/go/issues/39927 .  Parts of
this failing testcase were already fixed in the past, this is the remaining
piece
to be able to not force usage of gold in golang on aarch64 (see
https://github.com/golang/go/issues/22040#issuecomment-1430110400 ).

Creating a testcase by using only gas and ld.bfd requires the .reloc directives
as otherwise the relocated places are always left zeroed and hence don't
exhibit the problem.  But the a testcase is, for instance:

% cat rela.s
   .text
   .global _start
_start:
   ret

   .data
   .p2align 4
l: .long   0x, 0x
q: .quad   0x

   .reloc l, BFD_RELOC_64, q+42
   .reloc q, BFD_RELOC_64, l+84

% as rela.s -o rela.o
% ld -pie rela.o
% objdump -dRj .data a.out
a.out: file format elf64-littleaarch64

DYNAMIC RELOCATION RECORDS
OFFSET   TYPE  VALUE
0002 R_AARCH64_RELATIVE  *ABS*+0x00020032
00020008 R_AARCH64_RELATIVE  *ABS*+0x00020054


Contents of section .data:
 2 43111311  87333533   C..."""".353

Here it's obvious that address and addend are merely added to the existing
section content.  That's the bug.

The problem is that since inceptions of the aarch64 backend the src_mask
of all relocation descriptors in BFD were non-zero.  That's always wrong
for RELA relocs.  I have a patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40) since af31506c31a59a6edbb13498d6075fa704b801cd

[matz at suse dot de]

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

--- Comment #16 from Michael Matz  ---
Yes, the hacky patch is fine for you to use, it won't introduce further
problems
(knock on wood! :) ).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40) since af31506c31a59a6edbb13498d6075fa704b801cd

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #14 from Michael Matz  ---
Fixed in master.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30367] Performance regression after updating to 2.40

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Michael Matz  ---
Fixed in master.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40) since af31506c31a59a6edbb13498d6075fa704b801cd

[matz at suse dot de]

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

--- Comment #11 from Michael Matz  ---
The old (insertion-sort) code only added something to the output section list
if the considered section wasn't already either discarded or linked (by being
part of a group for instance).  That is done by lang_add_section.
This output section list is the sorted container into which further insertions
are done (and hence its length is the one determining performance).

The binary search tree code always adds all candidates to the tree (which in
our
unlucky case here mostly degrades to a linked list), and only then goes through
that tree to linearize it to a list which doesn't contain the discarded or
already linked input sections (group members).

So, the intermediate tree contains things that aren't ultimately going to be
output, blowing performance down the drain.  Otherwise the old insertion-sort
code and the now always used tree-based code are equivalent here.  But the
example contains _many_ groups, and all of them have a .debug_macro section
(and only that!) and it exists in many input files, so the difference is
a search-chain length of about 1500 in the insertion sort case and about 106000
in the binary tree case, and that factor goes in quadraticly into performance
(as said, the search tree is degraded in the example).

So, the solution is obvious: don't add something to the tree if it won't be
added to the linearized list later.  That requires some refactoring.

A hacky un-refactored patch for the above is below (relative to master).
It restores performance.

diff --git a/ld/ldlang.c b/ld/ldlang.c
index 4bec280b9df..7e0a9db51e3 100644
--- a/ld/ldlang.c
+++ b/ld/ldlang.c
@@ -687,6 +687,19 @@ output_section_callback_sort (lang_wild_statement_type
*ptr,
   if (unique_section_p (section, os))
 return;

+  /* Don't add sections to the tree when we already know that
+ lang_add_section won't do anything with it.  */
+  if (section->output_section != NULL)
+{
+  if (!link_info.non_contiguous_regions)
+   return;
+
+  /* SECTION has already been handled in a special way
+(eg. LINK_ONCE): skip it.  */
+  if (bfd_is_abs_section (section->output_section))
+   return;
+}
+
   node = (lang_section_bst_type *) xmalloc (sizeof (lang_section_bst_type));
   node->left = 0;
   node->right = 0;

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40) since af31506c31a59a6edbb13498d6075fa704b801cd

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

   Assignee|unassigned at sourceware dot org   |matz at suse dot de
 Status|NEW |ASSIGNED

--- Comment #10 from Michael Matz  ---
Yeah, that patch wouldn't help, it's in a different area.  Thanks for the
complete testcase.  I'm going to have a look here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30367] Performance regression after updating to 2.40

[matz at suse dot de]

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

--- Comment #2 from Michael Matz  ---
No need to dig into trying with an empty ROM.  It's easily reproducable with
many input files each being used in a wildstatement of a linker script.  It's a
quadraticness problem.  Proposed fix at 
  https://sourceware.org/pipermail/binutils/2023-April/127120.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30367] Performance regression after updating to 2.40

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at sourceware dot org   |matz at suse dot de

--- Comment #1 from Michael Matz  ---
So the specific feature heavily used in the linker script seems to be section
descriptions based on filenames.  I will try to create a reproducer for this
situation locally, but it would also help if I had a way to test it better in
your setup.  Is there any possibility you could make it so that I can
build/test your github project _without_ having access to the N64 ROM?  (E.g.
by replacing it with an all-zeros ROM for instance?  The result won't work, but
I'm only interested in building anyway.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gas/30120] x87: fucomp assembled as fucom

[matz at suse dot de]

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

--- Comment #5 from Michael Matz  ---
(In reply to Michael Matz from comment #4)
> commit 25a0d393c72 (with a little addition to a testcase to check for at
> least this problem)

FWIW, I've also checked all patterns touched by the initial patch now and also
don't see a further problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gas/30120] x87: fucomp assembled as fucom

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Michael Matz  ---
commit 25a0d393c72 (with a little addition to a testcase to check for at least
this problem)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gas/30120] x87: fucomp assembled as fucom

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

   Assignee|unassigned at sourceware dot org   |jbeulich at suse dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gas/30120] x87: fucomp assembled as fucom

[matz at suse dot de]

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

--- Comment #2 from Michael Matz  ---
Came in with bd7828084 "x86: use ModR/M for FPU insns with operands".

The proper Reg field of ModRM for the popping variant of fucom is '5' not '4'.
So this:

--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -651,7 +651,7 @@ fcompp, 0xded9, FP, NoSuf, {}
 fucom, 0xdd/4, i387, Modrm|NoSuf, { FloatReg }
 // alias for fucom %st(1)
 fucom, 0xdde1, i387, NoSuf, {}
-fucomp, 0xdd/4, i387, Modrm|NoSuf, { FloatReg }
+fucomp, 0xdd/5, i387, Modrm|NoSuf, { FloatReg }
 // alias for fucomp %st(1)
 fucomp, 0xdde9, i387, NoSuf, {}
 fucompp, 0xdae9, i387, NoSuf, {}

(didn't check the other insns touched by the patch)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gas/30120] x87: fucomp assembled as fucom

[matz at suse dot de]

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

--- Comment #1 from Michael Matz  ---
The problem exists in current master.  2.39 and 2.40 seem to be okay.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gas/30120] New: x87: fucomp assembled as fucom

[matz at suse dot de]

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

Bug ID: 30120
   Summary: x87: fucomp assembled as fucom
   Product: binutils
   Version: 2.41 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: matz at suse dot de
  Target Milestone: ---

% cat asm.s
fucomp %st(1)
% ./gas/as-new asm.s && objdump -d a.out
...
 <.text>:
   0:   dd e1   fucom  %st(1)

It should be 'dd e9fucomp %st(1)'.  This results in the x87 sometimes not
be popped and wrong results.  (GCC generates fucom{i,}p sometimes, of course).

Possibly some other mnemonics are affected as well, where there are popping (or
twice-popping) and non-popping variants, but this is one that effectively made
glibc miscompiled (in the sqrt implementation that uses 'isless').

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30079] Mingw ld : linking against an import lib causes ld to abort() at compare_section in ldlang.c

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Michael Matz  ---
(In reply to Christoph Reiter from comment #6)
> (In reply to Christoph Reiter from comment #5)
> > I did that in https://github.com/msys2/MINGW-packages/pull/15540 now which
> > fixed it for this example. Once it's in the repo I can ask the affected
> > users to try again.
> 
> All affected downstream users reported that it's working again for them.

Thanks.  After pondering I think it's the right thing to do, the input is sane
and it's (of course) fine that sections are only sorted by filename and not
otherwise, so that case needs dealing with.  I've committed a patch for this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/30079] Mingw ld : linking against an import lib causes ld to abort() at compare_section in ldlang.c

[matz at suse dot de]

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

--- Comment #3 from Michael Matz  ---
The guards are supposed to be moved only, not removed:

  if (!wild->filenames_sorted
  && (sec == NULL || sec->spec.sorted == none
  || sec->spec.sorted == by_none))
{
  return wild->rightmost;
}
  ...
  while (*tree) {
if (wild->filenames_sorted) {
  ...
  if (i > 0) ... continue; else if (i < 0) ... continue;
  if (fa || la) {
...
if (i > 0) ... continue else if (i < 0) ... continue;
  }
}
...
compare_section (sec->spec.sorted, section, (*tree)->section) < 0)
  ...

So it could only get to calling compare_section() (with sec->spec.sorted being
none or by_none) when ->filename_sorted _and_ it falls through the compare
based on these names (i.e. if filenames are equal and containing archives (if
they exist) are equal).

I probably convinced myself that this situation is not supposed to happen,
and as testcases were totally missing I didn't notice otherwise.

If you can tar up the object files I can take a look myself (I don't have 
cross compilers here, but cross binutils).  Or you add the guard
back again and see how that goes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gprofng/28972] gprofng libraries should be installed under $(pkglibdir)

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 CC||matz at suse dot de
 Status|RESOLVED|REOPENED

--- Comment #3 from Michael Matz  ---
This was wrong advise.  The shared _modules_ (the collectors, those which are
loaded by dlopen) should indeed be placed in $(pkglibdir).  But the shared
_library_ libgprofng.so.0 (and its various symlinks) need to stay in $(libdir).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gprofng/30043] libgprofng.so.* are installed to a wrong location

[matz at suse dot de]

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

--- Comment #3 from Michael Matz  ---
Proper shared libraries (those which programs link against via DT_NEEDED) have
to be placed in directories in which the dynamic linker searches for them.  You
can play games with DT_RUNPATH of course but that would not be the normal
action.

So, shared libraries need to be placed in $(libdir).  What you are talking
about are dynamic modules: ELF DSOs intended for dlopen, i.e. to be loaded at
runtime.
Usually the difference is already visual in the filenames: shared libs have
major.minor.micro version files and the foobar.so file is a symlink.  Modules
have just the .so file (and are usually not named 'lib*', though that's a
convention not always followed).

So the DSOs you create for modules (the collector stuff) indeed is properly
placed into $(pkglibdir), but the shared library libgprofng.so.0 (which we know
is one because the gprofng binary links against it) needs to be put into
$(libdir).

I don't know why H.J. suggested to put it into $(pkglibdir) but it's an
incorrect
advise.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/29849] ERROR: AddressSanitizer: global-buffer-overflow on address in spec_match ../../ld/ldlang.c:223 since 049522cae9798e51dd0c58566a9a2c61ba9100a9

[matz at suse dot de]

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

--- Comment #3 from Michael Matz  ---
Thanks Nick for cleaning up after me.  FWIW I was just testing an equivalent
patch on most targets without regressions, so it's good to go.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/19962] R_ARM_COPY relocation generated with -znocopyreloc

[matz at suse dot de]

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

--- Comment #6 from Michael Matz  ---
(And just FWIW: aarch64 binutils 2.36 and 2.37 don't have the problem either).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/19962] R_ARM_COPY relocation generated with -znocopyreloc

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at suse dot de
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Michael Matz  ---
So with current master binutils, without additional changes I don't see copy
relocs on aarch64 with the (adjusted for data size) example:

% cat data-ref.s
.globl _start
.p2align 4
_start:
ret

.data
.globl data_object
# .section.rodata,"a",@progbits
object_reference:
.quad data_object
.size object_reference,8

% cat libdata.s
.data
.globl data_object
.type data_object, %object
.size data_object, 8
data_object:
.quad 123

% ./gas/as-new -o data-ref.o data-ref.s
% ./gas/as-new -o libdata.o libdata.s
% ./ld/ld-new -shared -o libdata.so libdata.o
% ./ld/ld-new -znocopyreloc -o data-ref data-ref.o libdata.so
% readelf -rW data-ref
Relocation section '.rela.dyn' at offset 0x230 contains 1 entry:
Offset Info Type   Symbol's Value 
Symbol's Name + Addend
00411000  00010101 R_AARCH64_ABS64
data_object + 0

This doesn't change when the '.section rodata' directive is uncommented, i.e.
when the reference comes from a read-only section.  Still no copy-reloc.

(Without the -znocopyreloc linker option we do generate a copy reloc, but
that's expected).

So, right now I don't see anything in need for fixing.  This all was somewhat
related to a go problem: https://github.com/golang/go/issues/22040 .  If that
one still exists then it's different from _this_ problem report here.

If there's new info or a reproducer that still shows a problem, please reopen.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/28021] riscv: wrong double relaxation with LTO

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Michael Matz  ---
Fixed in master and 2.37.  Not planning further backports.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/28021] New: riscv: wrong double relaxation with LTO

[matz at suse dot de]

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

Bug ID: 28021
   Summary: riscv: wrong double relaxation with LTO
   Product: binutils
   Version: 2.37 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: matz at suse dot de
  Target Milestone: ---

This is related to the fix for PR22756, which turns out to be incomplete.
We have seen the problem with GCC11 and it needs LTO, which makes this a bit
involved to reproduce.  See https://bugzilla.suse.com/show_bug.cgi?id=1187542
for how it came to be, but it contains unrelated things.  Eventually I came up
with a single file testcase without compiler, but that involved a hex-edited
.o file.  After much back and forth I came up with a two-file testcase that
only involves assembler, no compiler, and that I believe faithfully reflects
the error
mode.  So, the files:

% cat relax-twice-1.s
.file   ""
.option pic
.text
# this align is here so that the .text section starts at 0x1000,
# in order to make matching of testcase results easier
.align 12
.globl  foobar_new
.weak   foobar_new
.type   foobar_new, @function
foobar_new:
jr ra
.size   foobar_new, .-foobar_new
.symver foobar_new, foobar@@New
.section.note.GNU-stack,"",@progbits

% cat relax-twice-2.s
.file   ""
.option pic
.text
.section.rodata.str1.8,"aMS",@progbits,1
.align  3
.LC0:
.string "%u"
.text
.align  1
.globl  relaxme
.type   relaxme, @function
relaxme:
addisp,sp,-32
addia2,sp,12
lla a1,.LC0
li  a0,0
sd  ra,24(sp)
callsscanf@plt
ld  ra,24(sp)
addisp,sp,32
jr  ra
.size   relaxme, .-relaxme
.align  1
.globl  foobar_new
.type   foobar_new, @function
foobar_new:
li  a0,1
ret
.size   foobar_new, .-foobar_new
.symver foobar_new, foobar@@New
.align  1
.globl  foobar_old
.type   foobar_old, @function
foobar_old:
addisp,sp,-16
sd  ra,8(sp)
callfoobar@plt
ld  ra,8(sp)
sneza0,a0
addisp,sp,16
jr  ra
.size   foobar_old, .-foobar_old
.symver foobar_old, foobar@Old
.section.note.GNU-stack,"",@progbits

% cat relax-twice.ver
Old {
global:
foobar;
relaxme;
local:
*;
};
New {
global:
foobar;
} Old;

% ../as-new -o relax-twice-1.o relax-twice-1.s
% ../as-new -o relax-twice-2.o relax-twice-2.s
% ../ld-new -o bla.so --relax -shared --version-script relax-twice.ver
relax-twice-1.o relax-twice-2.o
% nm bla.so
...
102c t foobar_new
1028 T foobar@@New
...

Note how these two symbols are supposed to point to the same address.  (The
stunt with the weak variant of foobar_new and foobar@@New in relax-twice-1.s
is only there to prime the internal symbol table of ld in the same way as
it would have been with LTO and the linker plugin.  The prevailing variants
are the ones from relax-twice-2.s)

The reason is the one already analyzed in PR22756: multiple entries in
sym_hashes[] pointing to the same symbol entry, such that the relaxation code
adjusts the same entry multiple times.  That is the situation always created
by aliases, and the PR22756 patch fixes it for hidden aliases (created by 
non-default symbol versions, i.e. foobar@BLA).  Of course the same can happen
with non-hidden aliases, as above demonstrates.

A definitely working fix would be to always check for duplicates, but a
slowdown
for that can then only be avoided by extending the elf symbol hash structure
to contain an already-handled flag.  The more immediate, but possibly also
still incomplete fix is simply:

--- a/bfd/elfnn-riscv.c
+++ b/bfd/elfnn-riscv.c
@@ -3993,7 +3993,7 @@ riscv_relax_delete_bytes (bfd *abfd, asection *sec,
bfd_vma addr, size_t count,
 foo becomes an alias for foo@BAR, and hence they need the same
 treatment.  */
   if (link_info->wrap_hash != NULL
- || sym_hash->versioned == versioned_hidden)
+ || sym_hash->versioned != unversioned)
{
  struct elf_link_hash_entry **cur_sym_hashes;


I will note that the problem exists for all targets that implement relaxation
that can also delete bytes from sections (it seems to all have been copied
around for decades), at least MIPS and AVR seem somewhat relevant still, but
it's also m10[23]00, cr16, h8300, ip2k, m32c, m68hc11, msp430, rl78, rx and
v850.  Only riscv goes to an effort to remidy the situati

[Bug ld/26018] --dynamic-list* doesn't work before -Bsymbolic and -Bsymbolic-functions

[matz at suse dot de]

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

--- Comment #9 from Michael Matz  ---
So, this commit is at fault, but it's already reported as PR26928 and that is a
duplicate of PR26407.  I was even involved in analyzing it there but obviously
forgot :-/

Then let me at least note that I disagree with the resolution of these bugs
that
all is well, and as intended.  I still think what I said here in comment #8,
namely that what libqt4 does here is sensible, and that --dynamic-list-data
should not be needed to make this case work.  (It does work-around the problem
here).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/26018] --dynamic-list* doesn't work before -Bsymbolic and -Bsymbolic-functions

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at suse dot de

--- Comment #8 from Michael Matz  ---
This might have broken usage in the wild.  In libqt4 this feature is used as
follows:

g++ ... -shared -Wl,-Bsymbolic-functions -Wl,--dynamic-list,QtCore.dynlist ...

with QtCore.dynlist only containing function names:

-
{
 extern "C" {
 "qt_startup_hook";
 "qt_addObject";
 "qt_removeObject";
 };
 extern "C++" {
 "QEventLoop::exec(QFlags)";
 };
};
-

The intent is that all functions are bound locally, except for the few ones
explicitely mentioned.  That worked fine with binutils 2.32, an excerpt from
the
relocations:

...
004e4bc8  047e0006 R_X86_64_GLOB_DAT  004e5900
_ZN7QString11shared_nullE + 0
...

I've singled out this one because it's important: this shared_null member _must
not_ be bound symbolically, there must be only one in the process image, and
there exist (non-PIE) binaries that contain COPY relocations on it.  So
relocations to this symbol need to stay in the shared lib, i.e. it must remain
dynamic.

With binutils 2.35 _ZN7QString11shared_nullE is bound symbolically, there's
no trace of it in the relocation of libQtCore.so.4 anymore, breaking stuff
in interesting ways (e.g. some executables hang at start).

I think what this (old) libqt4 link command is doing is reasonable: it wants
default behaviour for symbol binding, then overrides this for functions (to be
bound symbolically) and then overrides _that_ for some further functions (to
again be bound as per default, i.e. late).  I.e. the overall expectation that
data objects remain bound late with that command line seem sensible.

I haven't yet verified if this commit is really at fault, but it looks at least
related and I wanted to leave a trace in case I can't continue with analysis 
tomorrow.  If it's not this, then it's some other change since 2.32.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/27441] Small inconsistency in between gold and bfd

[matz at suse dot de]

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

--- Comment #20 from Michael Matz  ---
(In reply to Cary Coutant from comment #18)
> > > My understanding of when a shared object is needed:
> > > 
> > > * it is linked at least once in --no-as-needed mode (i.e. --as-needed a.so
> > > --no-as-needed a.so => needed)
> > > * or it has a non-weak definition resolving a reference from a live 
> > > section
> > > (not discarded by --gc-sections)
> > > 
> > > I think both LLD and gold's rules are like this.
> > 
> > Then they both have the same bug (in the second item of your list).  As Alan
> > explains, as-needed behaviour intends to reflect behaviour of static 
> > archives
> > (where that applies; here any difference in behaviour doesn't seem useful).
> > 
> > The only thing about weak definitions is that there may be validly multiple
> > ones
> > without error (the first one or the single non-weak definition wins).
> 
> This contradicts the ld manual:
> ...
> Note where it says "that at that point in the link satisfies a *non-weak*
> undefined symbol reference from a regular object file or, if the library is
> not found in the DT_NEEDED lists of other needed libraries, a *non-weak*
> undefined symbol reference from another needed dynamic library." (emphasis
> added)

Right.  This describes the static archive extraction rules.  It talks about
(non-weak i.e. strong) references, not about (weak) definitions.  Weak (and
strong) definitions do satisfy strong references, and hence invoke the above
rules about archive member extraction (and therefore should then also cause
the same behaviour for DT_NEEDED).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/27441] Small inconsistency in between gold and bfd

[matz at suse dot de]

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

--- Comment #17 from Michael Matz  ---
(In reply to Fangrui Song from comment #16)
> (In reply to Alan Modra from comment #12)
> > (In reply to Michael Matz from comment #11)
> > > Yes, I thought so as well, until I read ELF.txt again :)
> > 
> > Huh, I can hardly believe I was making such a completely wrong assumption. 
> > How stupid is that?  I just checked elflink.c plus archive.c code and ran a
> > test to properly convince myself I was wrong.  Yes, a weak definition does
> > indeed cause an archive element to be extracted to satisfy a strong
> > undefined reference.
> > 
> > Testing the binding of the definition was just plain wrong.
> 
> My understanding of when a shared object is needed:
> 
> * it is linked at least once in --no-as-needed mode (i.e. --as-needed a.so
> --no-as-needed a.so => needed)
> * or it has a non-weak definition resolving a reference from a live section
> (not discarded by --gc-sections)
> 
> I think both LLD and gold's rules are like this.

Then they both have the same bug (in the second item of your list).  As Alan
explains, as-needed behaviour intends to reflect behaviour of static archives
(where that applies; here any difference in behaviour doesn't seem useful).

The only thing about weak definitions is that there may be validly multiple
ones
without error (the first one or the single non-weak definition wins).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/27441] Small inconsistency in between gold and bfd

[matz at suse dot de]

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

--- Comment #11 from Michael Matz  ---
(In reply to Alan Modra from comment #8)
> (In reply to Michael Matz from comment #3)
> > % gcc -fPIC -Wl,--as-needed -fno-lto -shared -o good.so  bad4.c -L. -l2 -l1
> > % readelf-dW good.so | grep lib
> >  0x0001 (NEEDED) Shared library: [lib2.so]
> >  0x0001 (NEEDED) Shared library: [lib1.so]
> 
> I'd actually like to fix the above to *not* have DT_NEEDED lib2.so.  The
> reason is that as-needed was supposed to be modeled on the way archive
> entries are treated, and if you were using static libraries you'd find the
> weak func1 in lib2.a would not be enough to cause lib2.o to be extracted.. 

Yes, I thought so as well, until I read ELF.txt again :) :

* When the link editor searches archive libraries, it extracts archive
  members that contain definitions of undefined global symbols. The
  member's definition may be either a global or a weak symbol. The
  link editor does not extract archive members to resolve undefined
  weak symbols. Unresolved weak symbols have a zero value.

"may be either a global or a weak symbol".  It's weak undefs that don't cause
things to be pulled in, but a strong ref should pull in a weak def.

Independend of that I considered the current (non-LTO) behaviour more useful.

> Unfortunately I can't do that, libm.so.6 for instance is full of weak
> dynamic symbols.

(huh, I never noticed that; indeed)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/27441] Small inconsistency in between gold and bfd

[matz at suse dot de]

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

--- Comment #6 from Michael Matz  ---
Probably just one more corner case (the last one!) ;-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/27441] Small inconsistency in between gold and bfd

[matz at suse dot de]

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

--- Comment #4 from Michael Matz  ---
(I've now verified that it doesn't happen with older binutils (2.26 :) ) but
does with 2.36, with otherwise same toolchain (some random gcc-9 compiler), so
it's not any gcc component)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/27441] Small inconsistency in between gold and bfd

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

   Assignee|ccoutant at gmail dot com  |unassigned at 
sourceware dot org
  Component|gold|ld

--- Comment #3 from Michael Matz  ---
So, like this:

% cat lib1.c
int func1(void) { return 1; }
int func2(void) { return 2; }

% cat lib2.c
int __attribute__((weak)) func1(void) { return 3; }

% cat bad4.c
extern int func1(void);
extern int func2(void);

int callthem(void)
{
  return func1() + func2();
}

% gcc -fPIC -shared -o lib1.so lib1.c
% gcc -fPIC -shared -o lib2.so lib2.c
% gcc -fPIC -Wl,--as-needed -fno-lto -shared -o good.so  bad4.c -L. -l2 -l1
% readelf-dW good.so | grep lib
 0x0001 (NEEDED) Shared library: [lib2.so]
 0x0001 (NEEDED) Shared library: [lib1.so]

% gcc -fPIC -Wl,--as-needed -flto -shared -o bad.so  bad4.c -L. -l2 -l1
% readelf -dW bad.so | grep lib
 0x0001 (NEEDED) Shared library: [lib1.so]

(I'm resetting component to ld again, as I think the above shows the problem
clearly enough.  It's still possible that it's the gcc LTO plugin at fault,
though)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/27377] /usr/bin/ld.bfd: section .note.ABI-tag VMA [0000000000400190,00000000004001af] overlaps section .bss VMA [00000000000adc00,00000000004af3ff]

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at suse dot de

--- Comment #2 from Michael Matz  ---
Hah, -Ttext-segment indeed.  When I was looking at this
( https://bugzilla.opensuse.org/show_bug.cgi?id=1181741 ), I idly thought that
it
would be better if -Ttext would do something else than the traditional .text
section moving (for ELF formats), without realizing that this already exists
:-)

(For better or worse -Ttext is used by basically everything that wants
something
similar like grub, but what they _actually_ want is the behaviour of
 -Ttext-segment)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/27311] ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04

[matz at suse dot de]

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

--- Comment #5 from Michael Matz  ---
(In reply to Michael Matz from comment #4)
> (In reply to H.J. Lu from comment #2)
> > Please try users/hjl/pr26530/master branch:
> > 
> > https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/pr26530/
> > master
> 
> Yes, that patch series works, but I think we don't want to revert Alans
> patch but
> rather fix it :)

In particular, because it's crucial that the shared-lib symbol has a version
(with unversioned it links fine) I would expect the fix to be somehow involving
removing a difference between versioned and unversion symbols, not 
dealing with the as-needed behaviour of pulling or not pulling in members of
static archives.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/27311] ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04

[matz at suse dot de]

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

--- Comment #4 from Michael Matz  ---
(In reply to H.J. Lu from comment #2)
> Please try users/hjl/pr26530/master branch:
> 
> https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/pr26530/
> master

Yes, that patch series works, but I think we don't want to revert Alans patch
but
rather fix it :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/27311] ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04

[matz at suse dot de]

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

--- Comment #3 from Michael Matz  ---
FWIW, it's important that the symbol in question is defined in an indirect
shared lib with a symversion, and defined in an input object file itself.  I.e.
this is more self-contained:

% cat lib1.c
void inlib1(void) {}
% cat lib2.c
void inlib2(void) {}
% cat app.c
void inlib1(void) {}
int main()
{
  return 0;
}
% cat version.txt
LIBFOO {
  *;
};

% gcc -shared -fPIC -o lib1.so lib1.c -Wl,-version-script,version.txt
% gcc -shared -fPIC -o lib2.so lib2.c -Wl,--no-as-needed lib1.so
% gcc -c -flto app.c
% gcc app.o -L. -Wl,-rpath-link,. -l2
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: app.o
(symbol from plugin): undefined reference to symbol 'inlib1@@LIBFOO'
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
./lib1.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/27016] x86-64: GOTPCREL relaxation with abs symbol and REX byte creates incorrect code

[matz at suse dot de]

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

--- Comment #1 from Michael Matz  ---
This also happen in 2.35 of course.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/27016] New: x86-64: GOTPCREL relaxation with abs symbol and REX byte creates incorrect code

[matz at suse dot de]

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

Bug ID: 27016
   Summary: x86-64: GOTPCREL relaxation with abs symbol and REX
byte creates incorrect code
   Product: binutils
   Version: 2.36 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: matz at suse dot de
  Target Milestone: ---

Since the fix for PR ld/25749 and PR ld/25754, i.e. commit 382aae0632 ld
generates incorrect code in the following situation:
a) there's a GOTPCREL relocation (not REX_GOTPCRELX!)
b) the REX byte is necessary
c) the instruction is a mov
d) the relocation is against an absolute symbol

Due to the need of an absolute symbol an executable testcase is a bit
difficult, but this happens in the wild with old object files steming from
enterprise software linked during installation.  Can be reproduced with this:

% cat x.s
.file   "x.c"
.text
.comm   global_int,4,4
.globl  main
.type   main, @function
main:
.LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movqthesym@GOTPCREL(%rip), %r11
movl(%r11), %eax
leal1(%rax), %edx
movqthesym@GOTPCREL(%rip), %r11
movl%edx, (%r11)
movl$0, %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size   main, .-main
.ident  "GCC: (SUSE Linux) 9.2.1 20190903 [gcc-9-branch revision
275330]"
.section.note.GNU-stack,"",@progbits

% cat y.s
.globl thesym
thesym = 0x40402c

I've chose the value of this abs symbol to be the address of "global_int" in
the finally linked executable, so that it can be run.  Note how the main
function uses %r11 as destination register, i.e. the REX byte will be required
and must be correct in the rewritten instruction.

% as -mrelax-relocations=no -o x.o x.s
% as -mrelax-relocations=no -o y.o y.s
% ld-new --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /usr/lib64/crt1.o /usr/lib64/crti.o
/usr/lib64/gcc/x86_64-suse-linux/9/crtbegin.o x.o y.o -lc 
/usr/lib64/gcc/x86_64-suse-linux/9/crtend.o /usr/lib64/crtn.o
% ./a.out
Segmentation fault

This is because the input .o file has this:
   4:   4c 8b 1d 00 00 00 00mov0x0(%rip),%r11# b 
7: R_X86_64_GOTPCRELthesym-0x4

(Note: not REX_GOTPCREL).  And the output a.out has this:

004010f2 :
  4010f2:   55  push   %rbp
  4010f3:   48 89 e5mov%rsp,%rbp
  4010f6:   4c c7 c3 2c 40 40 00rex.WR mov $0x40402c,%rbx
  4010fd:   41 8b 03mov(%r11),%eax

Note how the destination of insn main+4 is %rbx and there's an invalid REX
byte.

This is all because of this hunk in elf_x86_64_convert_load_reloc:

  if (r_type == R_X86_64_REX_GOTPCRELX)
rex = bfd_get_8 (abfd, contents + roff - 3);
  else
rex = 0;

  if (opcode == 0x8b)
{
  if (abs_symbol && local_ref)
to_reloc_pc32 = FALSE;
  if (to_reloc_pc32)
// just rewrite into lea, don't touch REX byte
  else
// rewrite into mov, and fiddle with REX byte

So, with an absolute symbol the code expect to be able to change the REX byte,
but with mere GOTPCREL relocs as here, it can't.  Possible patch for this:


Fix for bsc#1179341

the movload->movconst relaxation can be done only with REX
rewriting, and hence needs a GOTPCRELX relocation.  With old object
files we might still see GOTPCREL relocs, even with REX bytes available.
We still can't do such rewriting and hence need to stay with the old
rewriting into a lea.
diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
index 549a8be6a6..b89b0023db 100644
--- a/bfd/elf64-x86-64.c
+++ b/bfd/elf64-x86-64.c
@@ -1731,7 +1731,7 @@ elf_x86_64_convert_load_reloc (bfd *abfd,

   if (opcode == 0x8b)
{
- if (abs_symbol && local_ref)
+ if (abs_symbol && local_ref && rex)
to_reloc_pc32 = FALSE;

  if (to_reloc_pc32)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/26936] ld drops relocation for .text.__x86.get_pc_thunk.bx

[matz at suse dot de]

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

--- Comment #22 from Michael Matz  ---
(In reply to Fangrui Song from comment #20)
> (I thought that .gnu.linkonce was deprecated almost 20 years ago and we
> should phase out linkonce instead of adding more compatibility code...)

Deprecation != not used anymore in the wild.  In this case it's crt files
compiled
with options intentionally emitting linkonce, not comdat, sections, also for
compatibility.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/26936] ld drops relocation for .text.__x86.get_pc_thunk.bx

[matz at suse dot de]

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

--- Comment #17 from Michael Matz  ---
(In reply to H.J. Lu from comment #15)
> My /lib/crti.o has
> 
> COMDAT group section [1] `.group' [__x86.get_pc_thunk.bx] contains 1
> sections:
>[Index]Name
>[8]   .text.__x86.get_pc_thunk.bx

Sure, which is why I have provided sources.  We have to support old systems
with oldish glibc, and that has linkonce sections in those files.

Thanks for the patch, it works.  But I think you want to check kept != NULL
before going into the loop.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/26551] A definition referenced by an unneeded (--as-needed) shared object should be exported

[matz at suse dot de]

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

--- Comment #9 from Michael Matz  ---
I think ld.bfd is completely fine to not export exe symbols only referenced by
mentioned but not otherwise needed libraries.  It's follows from traditional
behaviour that executables don't export any symbols, which aren't obviously
needed
in a static linking model, which is why -E exists.  I could a libararies that
isn't necessary by anything from the executable containing a back-reference to
the executable to not be obvious.  If you really need to support this situation
you would normally need to use -E, which btw is documented to sometime be
necessary with dlopen games:

   -E
   ...
   If you use "dlopen" to load a dynamic object which needs to refer
   back to the symbols defined by the program, rather than some other
   dynamic object, then you will probably need to use this option when
   linking the program itself.

The more controled way for this is --dynamic-list.

Doing what you suggest would break the following invariant: you can remove any
unneeded as-needed -lxyz arguments from the link command and end up with the
same
binary.  This is basically the set of libraries that 'ldd -u' would print, and
is
why as-needed was implement to start with, to save that manual manual work.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/26530] Inconsistency in between bfd and gold about -Wl,--as-needed

[matz at suse dot de]

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

--- Comment #1 from Michael Matz  ---
FWIW, I think the gold behaviour is the correct one.  The order of libraries
on the cmdline is significant, and libfoo.so does fulfill the symbol request,
so the object from libtest.a shouldn't be considered.  No matter if LTO is or
isn't
involved.  (In fact also bfd ld doesn't use the archive without LTO mode)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/26407] Global symbol reference breaks without -Bsymbolic-functions

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at suse dot de

--- Comment #8 from Michael Matz  ---
I wonder if we shouldn't mark symbols that are internalized but referenced (and
hence have relocs to them removed) and still exported such that when a binary
is created that contains a copy relocation to them could at least be warned
about 
when creating such binary.  There are a couple bits available in the symbol
table
entries.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/25708] nm -D doesn't display symbol version for dynamic symbols

[matz at suse dot de]

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

--- Comment #10 from Michael Matz  ---
(In reply to H.J. Lu from comment #9)
> > 
> > Is it really a good idea to change the output format of basic tools that
> > might be
> > used in machine processing context?  (And I note there doesn't seem to be an
> > cmdline option to get the old behaviour back, so fixing the problem now
> > entails
> > further massaging of nm output to cut off /@.*/ )
> 
> Is this PR 26302?  A patch is at

No.  perf does the moral equivalent of:

% ( echo "{"; nm -D input.so | awk '{print $1";"}'; echo "}" ) > thelist
% ld ... --dynamic-list=thelist

Of course 'thelist' now contains @ characters, because nm -D shows symversions,
and that's what ld is complaining about:

thelist:2: ignoring invalid character `@' in script
thelist:2: syntax error in dynamic list
collect2: error: ld returned 1 exit status

The build system of simply isn't prepared to deal with these symversions.
So one of several things need to happen:
a) nm -D doesn't print symversions, unless explicitely requested
b) nm -D continues to print them, but with an option to disable them
c) perf Makefile is changed to filter out any /@.*/ in the nm output

I'm not sure how widespread such usage of nm is, and hence how often fix (c)
would have to be applied in the wild.  Fixing such packages would at least
be easier if nm had an option to disable printing them (i.e. (b)).  But maybe
it's best to not change traditional behaviour of nm at all, i.e. change (a),
and revert to not printing symversions by default.

I don't know what's best.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/25708] nm -D doesn't display symbol version for dynamic symbols

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at suse dot de

--- Comment #8 from Michael Matz  ---
This breaks at least the perf build from linux kernel 5.7 as nm is used to
construct a symbol list for feeding into ld, which now contains '@' characters
which aren't liked by ld (of course).  See e.g.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887397

Is it really a good idea to change the output format of basic tools that might
be
used in machine processing context?  (And I note there doesn't seem to be an
cmdline option to get the old behaviour back, so fixing the problem now entails
further massaging of nm output to cut off /@.*/ )

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/25593] --as-needed breaks DT_NEEDED order with linker plugin

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at suse dot de

--- Comment #1 from Michael Matz  ---
Just to be explicit: also works fine without -flto when compiling t.c.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/25210] aarch64: -fix-cortex-a53-835769 --fix-cortex-a53-843419 lead to invalid operation

[matz at suse dot de]

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

--- Comment #1 from Michael Matz  ---
FWIW, master still has the same problem and the same patch helps.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/25210] New: aarch64: -fix-cortex-a53-835769 --fix-cortex-a53-843419 lead to invalid operation

[matz at suse dot de]

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

Bug ID: 25210
   Summary: aarch64: -fix-cortex-a53-835769
--fix-cortex-a53-843419 lead to invalid operation
   Product: binutils
   Version: 2.33
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: matz at suse dot de
  Target Milestone: ---

This came up in our distro build when updating to binutils 2.33 (2.32 was still
fine) which then fails building GCC.  But it can actually be reproduced by
the testcases included in binutils itself, when using both fix-arrata options
at the same time:

(on an aarch64 system, from a binutils checkout 2.33 branch):
% ../configure --disable-gold; make CFLAGS=-g -j8
% cd ld
% gcc -c -o bla.o ../../ld/testsuite/ld-aarch64/erratum835769.s
% ld bla.o
ld: warning: cannot find entry symbol _start; defaulting to 00400078
(i.e. works)
% ./ld-new --fix-cortex-a53-835769 --fix-cortex-a53-843419=full bla.o
./ld-new: can not size stub section: invalid operation
./ld-new: warning: cannot find entry symbol _start; defaulting to
00400078
./ld-new: linker stubs: file class ELFCLASSNONE incompatible with ELFCLASS64
./ld-new: final link failed: file in wrong format

This might be related to the fix for PR24373, as that seems the only relevant
change re linker stubs on aarch64 between 2.32 and 2.33.  I haven't checked if
master has the same problem.

I've debugged this a little bit, and the error happens because
elf64_aarch64_size_stubs iterates over all input_bfds, and over all sections
and tries to determine if it needs the fixes; while doing so it calls (of
course) bfd_malloc_and_get_section, which breaks because one of the input bfds
doesn't have an iovec.  This bfd is precisely the one created for the stubs.
So the iteration over all input BFDs is confused when it inspects the stub_bfd
for needing stubs.  I.e. this patch helps the immediate cause:

--- ../../bfd/elfnn-aarch64.c.mm2019-09-09 13:19:43.0 +
+++ ../../bfd/elfnn-aarch64.c   2019-11-20 11:44:00.0 +
@@ -4312,7 +4312,8 @@ elfNN_aarch64_size_stubs (bfd *output_bf

   for (input_bfd = info->input_bfds;
   input_bfd != NULL; input_bfd = input_bfd->link.next)
-   if (!_bfd_aarch64_erratum_835769_scan (input_bfd, info,
+   if (input_bfd != stub_bfd
+   && !_bfd_aarch64_erratum_835769_scan (input_bfd, info,
   _erratum_835769_fixes))
  return FALSE;

@@ -4327,6 +4328,7 @@ elfNN_aarch64_size_stubs (bfd *output_bf
   for (input_bfd = info->input_bfds;
   input_bfd != NULL;
   input_bfd = input_bfd->link.next)
+   if (input_bfd != stub_bfd)
{
  asection *section;

But I'm not sure if this is complete, or the correct place; or if perhaps the
check should be based on sections being linker created, though I think the
above is better.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/23008] Stack Overflow(Stack Exhaustion) in demangle related functions

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at suse dot de

--- Comment #11 from Michael Matz  ---
All seems to work as designed.  The testcase contains a large number of 'F'
characters, and demangling each one of them entails:

5  0x005ec0f8 in demangle_nested_args (work=0x7fffd540,
mangled=0x7fffd2a0, 
declp=0x7f800050) at ../../libiberty/cplus-dem.c:4713
4713  result = demangle_args (work, mangled, declp);
#4  0x005ea8f9 in demangle_args (work=0x7fffd540,
mangled=0x7fffd2a0, declp=0x7f800050)
at ../../libiberty/cplus-dem.c:4659
4659  if (!do_arg (work, mangled, ))
#3  0x005eb99e in do_arg (work=0x7fffd540, mangled=0x7fffd2a0,
result=0x7f7ffbe0)
at ../../libiberty/cplus-dem.c:4332
4332  if (!do_type (work, mangled, work->previous_argument))
#2  0x005cbf15 in do_type (work=0x7fffd540, mangled=0x7fffd2a0,
result=0x603318d0)
at ../../libiberty/cplus-dem.c:3719
3719  if (!demangle_nested_args (work, mangled, )
#1  0x005ec0f8 in demangle_nested_args (work=0x7fffd540,
mangled=0x7fffd2a0, 
declp=0x7f7ff370) at ../../libiberty/cplus-dem.c:4713
4713  result = demangle_args (work, mangled, declp);

That progresses *mangled by one character.  When compiled with clang, the above
sequence of five calls needs 3296 bytes on the stack.  The testcase
contains more than 2542 'F' characters in a row, and together that needs more
than 8MB of stack, leading to the abort.

When compiled with GCC -fsanitize-address the above sequence only needs 912
bytes on stack (per 'F' character), so it progresses until 
(gdb) p *mangled
$10 = 0x78b6cc <mbuffer+9196> 'F' ...
before segfaulting due to stack overflow (with clang it only gets until
mbuffer+2550).

When compiled without sanitizer (with GCC) the above sequence of calls only
needs 400 bytes per stack.  The testcase contains 11586 'F' characters, so that
is within the normal stack limit and no problem occurs.

If the compiler is more clever (the above is with gcc-6 and -O0) then the
sequence of calls will need less stack space, and hence not reproduce the
problem.  I'm not sure if anything needs fixing, the demangler works as
designed, you ask it to demangle a nested structure that's 11000 levels deep,
and a stack overflow occurs.  As expected.

-- 
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/22981] ld: BFD (GNU Binutils) 2.30.0.20180226-0 assertion fail ../../bfd/elf.c:3564

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at suse dot de

-- 
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/22868] Gold does not select proper symbol visibility when used with LLVM gold-plugin

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at suse dot de

--- Comment #1 from Michael Matz  ---
The second testsuite fail in llvm has probably the same reason, but just for
completeness: visiblity.ll fails.  It essentially has a weak and a non-weak
definition of the same symbol:

one.ll:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define weak protected void @foo() {
  ret void
}

two.ll:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"

define void @foo() {
  ret void
}

But the linked result (with ld.gold):

  Symbol {
Name: foo (44)
Value: 0x290
Size: 1
Binding: Weak (0x2)
Type: Function (0x2)
Other [ (0x3)
  STV_PROTECTED (0x3)
]
Section: .text (0x5)
  }

So the binding is weak.  In ELF symbol resolution rules a non-weak definition
overrides a weak one, so it should actually be global.  (In this case the
STV_PROTECTED is correct)

ld.bfd gets this right.

-- 
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/21964] __start_SCN symbols aren't exported anymore

[matz at suse dot de]

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

--- Comment #11 from Michael Matz  ---
So I think in addition to what my patch did the following also needs solving:
* if a __start symbol is supposed to be created, then it should be created!
  (i.e. not merely use some random other symbol coming from some dyn-object)
* possibly the create-copy-relocs from protected symbols needs adjustments
  to ignore start/stop symbols, though the above item should already make
  it so that this path isn't entered anymore.

-- 
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/21964] __start_SCN symbols aren't exported anymore

[matz at suse dot de]

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

--- Comment #10 from Michael Matz  ---
Created attachment 10356
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10356=edit
another testcase showing unpatched binutils broken

Like with this new testcase.  The difference
is that with this the shared library is build with installed tools (for me old
binutils and gcc, i.e. simulating binary libs people will have installed from
their distro), but the app itself is linked with new linker.

With unpatched binutils (2.29 branch, but shouldn't matter):

% make
cc -g   -c -o app.o app.c
cc -g -fPIC   -c -o lib.o lib.c
cc -shared -o liborphan.so lib.o
ln -sf ../ld/ld-new ld
cc -B./ -o app app.o liborphan.so -ldl -Wl,-R,.
./ld: warning: type and size of dynamic symbol `__stop___verbose' are not
defined
./ld: warning: type and size of dynamic symbol `__start___verbose' are not
defined
./app
main: wrong __start___verbose
make: *** [all] Error 2

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

[Bug ld/21964] __start_SCN symbols aren't exported anymore

[matz at suse dot de]

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

--- Comment #9 from Michael Matz  ---
(In reply to Michael Matz from comment #8)
> Looking at this, that ld-gc/pr20002 doesn't fail without the patch from
> comment #4 is a nice thing, but I think it succeeds for the wrong reasons. 

The testcase specifically works of course (without patch) because with new
binutils these symbols were hidden, and hence not part of the exported set,
so dynamic objects involved in the link couldn't have created this problem.

But I bet that if you build a shared lib with old binutils (so the __start
symbol is exported), and use new binutils to create a shared lib linking
against that old shared lib (in such a way that both contain same-named
orphane sections) then the same faults can be seen also without patch.

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

[Bug ld/21964] __start_SCN symbols aren't exported anymore

[matz at suse dot de]

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

--- Comment #8 from Michael Matz  ---
You mean it shows an additional issue, I wasn't saying my patch is perfect,
merely that it fixes my reported problem.  I think it's the same reason of why
the testcase ld-gc/pr20022 fails with the proposed patch.

bfd_elf_define_start_stop doesn't want to create a __start symbol
if there already exists a defined one in the hash table, even if that comes
from a dynamic object.  Normal symbols would have gone through
_bfd_elf_merge_symbol, which would have overridden the definition from a
dynamic object with the one from regular files if the latter has non-default
visibility.

But bfd_elf_define_start_stop simply gives up, doesn't create the proper
local (hidden/protected whatever you want to call it) __start symbol and hence
resolves regular refs against the one from the dynamic object (invalidly so).

Looking at this, that ld-gc/pr20002 doesn't fail without the patch from comment
#4 is a nice thing, but I think it succeeds for the wrong reasons.  Something
is fishy with how those start/stop symbols are created, IMHO.

-- 
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/21964] __start_SCN symbols aren't exported anymore

[matz at suse dot de]

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

--- Comment #6 from Michael Matz  ---
Created attachment 10354
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10354=edit
tarball with testcase

Here is one.  Unlike libqb it's not using dl_iterate_phdr and then dlopen with
the known name to get the shared lib, but instead dlopen directly, but that
doesn't matter here.

It's supposed to be extracted inside the binutils build directory, it calls
../ld/ld-new directly.  I.e.:

% cd build
% tar xvf orphan.tar.gz && cd orphan
% make
gcc -o app app.c -ldl
gcc -c -fPIC -o lib.o lib.c
/usr/bin/ld -shared -o liborphan.so lib.o
./app && echo okay
okay
../ld/ld-new -shared -o liborphan.so lib.o
./app
can't find __start___verbose
make: *** [failing] Error 2
% 

The above happens when the system /usr/bin/ld is still pre-2.29.  With the
patch
it's:

% make
/usr/bin/ld -shared -o liborphan.so lib.o
./app && echo okay
okay
../ld/ld-new -shared -o liborphan.so lib.o
./app
%

-- 
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/21964] __start_SCN symbols aren't exported anymore

[matz at suse dot de]

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

--- Comment #4 from Michael Matz  ---
Created attachment 10353
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10353=edit
Tentative patch

Well, the problem is quite obvious.  Just compile this:

% cat t.c
#include 
extern void * __start___verbose, * __stop___verbose;
int foo(void)
{
  static int my_var __attribute__((section("__verbose"))) = 5;
  if (__start___verbose == __stop___verbose) assert(0);
  if (my_var == 5) return 0;
  else return -1;
}
% gcc -c -fPIC t.c
% ./ld/ld-new -shared t.o
% readelf -rsW a.out
...

It should have __start___verbose in the dynamic symbols but hasn't.

FWIW, I've come up with this patch.  The idea is to make the symbols protected
and always resolve them locally even if the (completely broken IMHO, but
that's an old story) extern_protected_data flag says otherwise.

-- 
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/21964] __start_SCN symbols aren't exported anymore

[matz at suse dot de]

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

--- Comment #2 from Michael Matz  ---
(In reply to H.J. Lu from comment #1)
> What should happen when there is _verbose section in more than one shared
> object?

As I said, the code in question uses dlsym, so nothing interesting happens,
multiple symbols in different shared objects have different addresses.

If you're worried about symbolic references from inside shared objects (even
though we have no indication that this is a problem in the real world, it has
always worked like this) then at the very least they should be made protected
so that they are bound internally, but also exported.  The latter part is
what is important for existing code.

-- 
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/21964] __start_SCN symbols aren't exported anymore

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 CC||amodra 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 ld/21964] New: __start_SCN symbols aren't exported anymore

[matz at suse dot de]

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

Bug ID: 21964
   Summary: __start_SCN symbols aren't exported anymore
   Product: binutils
   Version: 2.29
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: matz at suse dot de
  Target Milestone: ---

Commit cbd0eecf reworked the provision of __start_ and __stop_ symbols for
sections with C-representable names (e.g. to always provide them, not only
for orphaned sections).  Amongst other things it also made all these provided
symbols hidden.  Alans later rewrite (commit 7dba9362) of this code didn't
change this.  That actively breaks existing code.

E.g. in libqb (used by pacemaker) the logging facility uses per-call-site
static variables as log descriptors.  These are all placed into a section named
__verbose.  There's a routine that registers all such sections by walking
over all loaded shared libs via dl_iterate_phdr, and looking for
__start__verbose and __stop___verbose symbols via dlsym.

That seems a reasonable approach to implement such facility, and making the
symbols hidden defeats this.  The commit message indicates only "so that they
don't conflict" as reason for making them hidden.  At least for these symbols
for orphaned sections I don't see any indication that this was actually a
problem.  OTOH it breaks existing usage.

So, can we please have back the old behaviour at least for the __start/__stop
symbols for orphaned sections?

(Yes, there are multiple ways to work-around this problem on the user side,
the point is that they shouldn't be necessary).

-- 
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/21884] [2.29/2.30 Regression] ld segfaulting building memtest86

[matz at suse dot de]

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

--- Comment #29 from Michael Matz  ---
And commit b7a18930 from Nick fixed it on master for a x86_64 hosted binutils
(I'm qualifying this because I haven't checked a i586 hosted binutils yet).

So at the very minimum this patch needs to be on the 2.29 branch as well.

As testcase my comment #28 should suffice.

-- 
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/21884] [2.29/2.30 Regression] ld segfaulting building memtest86

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||matz at suse dot de
 Resolution|FIXED   |---

--- Comment #28 from Michael Matz  ---
This still reproduces for me, on i586 and on x86_64.  I don't need to build
binutils in any special way, on my host x86_64, with gcc 4.7:

% git status
# On branch binutils-2_29-branch
...
nothing added to commit but untracked files present (use "git add" to track)
% mkdir dev && cd dev
% ../configure --disable-gdb
% make CFLAGS=-g -j8
...
% echo "" > foo
% cat memtest.lds
OUTPUT_FORMAT("elf32-i386");
OUTPUT_ARCH(i386);

ENTRY(_start); 
SECTIONS {
. = 0x1;
_start = . ;
.data : {
*(.data)
}
}
% ./ld/ld-new -T memtest.lds -b binary foo -o memtest

valgrind shows me this backtrace:

==3890== Invalid read of size 4
==3890==at 0x49386B: _bfd_elf_create_got_section (elflink.c:158)
==3890==by 0x4D3B62: elf_i386_link_setup_gnu_properties (elf32-i386.c:7025)
==3890==by 0x42C393: gldelf_x86_64_after_open (eelf_x86_64.c:1169)
==3890==by 0x42373C: ldemul_after_open (ldemul.c:64)
==3890==by 0x418E3D: lang_process (ldlang.c:7093)
==3890==by 0x41D1E5: main (ldmain.c:437)
==3890==  Address 0x28 is not stack'd, malloc'd or (recently) free'd

So yes, the elf_i386_link_setup_gnu_properties function is most definitely
called.

-- 
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/17592] x86-64 linker generates wrong PLT for large model

[matz at suse dot de]

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

--- Comment #3 from Michael Matz matz at suse dot de ---
(In reply to H.J. Lu from comment #2)
 It is an interesting idea.

Yeah, that's how I tested the large model back in the days when I implemented
some of it.  Never got around to actually change the PLT layout.

 If we place .plt just after .text, there
 may be readonly sections before .got, the distance between .plt and
 .got.plt can still be big.

Yes, unfortunately.

 If we place .plt just before .got, the
 text segment will have text, readonly data and followed by text. Do
 we want to do that?

At least it wouldn't change the executable view of the ELF files, those
sections would still be contained in the read-only-exec segment.  Also the
GNU_RELRO (writable, but only during loading) part could be moved after .got.
Thereby .got would be first in the RW segment and .plt last in the RE segment,
right next to each other.

-- 
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/17592] x86-64 linker generates wrong PLT for large model

[matz at suse dot de]

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

--- Comment #5 from Michael Matz matz at suse dot de ---
(In reply to H.J. Lu from comment #4)
 When there is a large readonly section,  it makes no differences between
 
 text, plt, readonly, got
 
 and
 
 text, readonly, plt, got
 
 since text needs to reach plt and plt needs to reach got.

Yes, but text reaching PLT is trivial with the large code model.  But PLT
reaching GOT requires changing the PLT layout.  The reason for my idea
of moving the PLT was to avoid doing that.  And with a large readonly only
the latter layout achieves that.  So I think that should be the default layout.

-- 
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/17592] x86-64 linker generates wrong PLT for large model

[matz at suse dot de]

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

Michael Matz matz at suse dot de changed:

   What|Removed |Added

 CC||matz at suse dot de

--- Comment #1 from Michael Matz matz at suse dot de ---
Back in http://www.sourceware.org/ml/binutils/2006-03/msg00276.html
I suggested to place .plt after .text so that PLT and GOT are nearer
to each other.  In that case the large PLT layout would only need to
be used if there were more that 100 million PLT slots (and GOT entry).

Nevertheless, for full large model support you're right, the large PLT
layout needs to be implemented.

-- 
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/15167] New: ld merges gnu_unique def and normal ref into normal symbol

[matz at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=15167

 Bug #: 15167
   Summary: ld merges gnu_unique def and normal ref into normal
symbol
   Product: binutils
   Version: 2.24 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: m...@suse.de
Classification: Unclassified


This came up over at http://gcc.gnu.org/ml/gcc/2013-02/msg00227.html
describing a strange mismatch between two symbols that are unique, but
in the shared object one is normal and the other is unique.  I traced
this back to an ordering problem in ld at
http://gcc.gnu.org/ml/gcc/2013-02/msg00239.html .  The binutils involved
there are 2.21.1, but current upstream still exhibits the issue.  I made a
minimal testcase with two asm files:

% cat unique1.s
.file   unique.cc
.weak   _ZN1SIiE1iE
.section.bss._ZN1SIiE1iE,awG,@nobits,_ZN1SIiE1iE,comdat
.align 4
.type   _ZN1SIiE1iE, @gnu_unique_object
.size   _ZN1SIiE1iE, 4
_ZN1SIiE1iE:
.zero   4
.ident  GCC: (GNU) 4.6.1 20110505 (prerelease)
.section.note.GNU-stack,,@progbits

% cat unique2.s
.file   unique.cc
.text
.align 2
.globl  _ZN1SIiE3getEv
.type   _ZN1SIiE3getEv, @function
_ZN1SIiE3getEv:
.LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movq%rdi, -8(%rbp)
movq_ZN1SIiE1iE@GOTPCREL(%rip), %rax
movl(%rax), %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size   _ZN1SIiE3getEv, .-_ZN1SIiE3getEv
.ident  GCC: (GNU) 4.6.1 20110505 (prerelease)
.section.note.GNU-stack,,@progbits

% gcc -c unique1.s unique2.s
% ./ld/ld-new -shared -o unique-ok.so unique2.o unique1.o
% ./ld/ld-new -shared -o unique-bad.so unique1.o unique2.o
% nm -D unique-bad.so | grep _ZN1SIiE1iE
00200398 B _ZN1SIiE1iE
% nm -D unique-ok.so | grep _ZN1SIiE1iE
00200398 u _ZN1SIiE1iE

In difference is that for unique-ok.so the reference to _ZN1SIiE1iE comes
first (in unique2.o), then the definition (in unique1.o), and that results
correctly in a global unique symbol exported from the DSO.
For unique-bad.so the definition comes first, and the uniqueness seems to
get lost when the normal reference is seen, so a normal global (not even weak)
symbol is now exported from the DSO.

This can (and as the thread at gcc@ shows actually does) lead to problems
when the system relies on some symbols to be indeed globally unique.
The empty_rep static member of libstdc++'s string and wstring templates
is one example.

As said, this is broken in at least 2.21.1 and in current trunk.  FWIW,
the C++ source I used to initially generate the above asms is:

template typename T
struct S {
static T i;
T get();
};
template typename T T ST::i;
template  int Sint::get() { return i; }

compiled with -fPIC, and then split the .s into two by hand.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14915] --copy-dt-needed-entries not working

[matz at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=14915

Michael Matz matz at suse dot de changed:

   What|Removed |Added

 CC||matz at suse dot de

--- Comment #1 from Michael Matz matz at suse dot de 2012-12-04 14:06:26 UTC 
---
Behaviour also doesn't change if we include objects that refer to stuff from
libm or libt1 into libt2.  I tried to debug ld a bit to see where this is
supposed to be handled but got lost after two hours.  It seems that some
handling of dt_needed entries in elf32.xm:gld*_after_open is only done
for executables, but even creating an executable doesn't help.

In any case, I couldn't find any code that really tries to add DT_NEEDED
entries from referred libraries to the output file.  The code in
elflink.c:elf_link_add_object_symbols at least only adds to the htab-needed
list on those entries (and 'libm.so.6' is included there), but doesn't actually
call elf_add_dt_needed_tag on those entries (and nobody else does
either).

It certainly doesn't work as documented or expected (with my expectations).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14915] --copy-dt-needed-entries not working

[matz at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=14915

--- Comment #5 from Michael Matz matz at suse dot de 2012-12-04 14:39:58 UTC 
---
(In reply to comment #4)
 This option is renamed from --add-needed:
 
 http://sourceware.org/ml/binutils/2004-07/msg00093.html

Yes, but why are you mentioning that?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14915] --copy-dt-needed-entries not working

[matz at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=14915

--- Comment #7 from Michael Matz matz at suse dot de 2012-12-04 14:44:50 UTC 
---
(In reply to comment #5)
 (In reply to comment #4)
  This option is renamed from --add-needed:
  
  http://sourceware.org/ml/binutils/2004-07/msg00093.html
 
 Yes, but why are you mentioning that?

In particular, from that thread is referred the GCC problem that you wanted
to fix with adding --no-add-needed:
http://gcc.gnu.org/ml/gcc/2004-04/msg01130.html

The problem specifically was that libunwind was added to DT_NEEDED because
it was itself DT_NEEDED by libgcc_s, and it was said that this was how the
linker is supposed to work.  Now, meanwhile the default got switched, i.e.
--no-copy-dt-needed-entries is the default, but we're supposed to be able
to switch back with --copy-dt-needed-entries.  And this bug report is about
the fact, that this doesn't work.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14915] --copy-dt-needed-entries not working

[matz at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=14915

--- Comment #8 from Michael Matz matz at suse dot de 2012-12-04 14:56:09 UTC 
---
Let's create a different testcase showing also similar symptoms of not
correctly adding DT_NEEDED entries as documented, this time to search scopes:

% cat bla.c
extern double sin (double);
double f (double i) { return sin (i); }
% gcc -c -fPIC bla.c
% ./ld/ld-new -shared -o libt1.so bla.o -lm -zdefs
% readelf -d libt1.so | grep NEEDED
 0x0001 (NEEDED) Shared library: [libm.so.6]

Everything fine so far.  Now we want to generate libt2 also referring
to a libm function, want to link it only with libt1 and expect that
there's some way to include libm into the search scopes with some option to ld.
 The documented option is --copy-dt-needed-entries, so:

% cat bla2.c
extern double f (double);
extern double sin (double);
double g (double i) { return f(i) + sin (i); }
% gcc -c -fPIC bla2.c

So, bla2 refers to functions of libt1 and to libm, but still:

% ./ld/ld-new -shared -o libt2.so bla.o --copy-dt-needed-entries -L. -lt1 -z
defs
bla2.o: In function `g':
bla2.c:(.text+0x22): undefined reference to `sin'

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14915] --copy-dt-needed-entries not working

[matz at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=14915

--- Comment #3 from Michael Matz matz at suse dot de 2012-12-04 14:12:29 UTC 
---
(In reply to comment #2)
 
 gcc -o libt2.so -shared -Wl,--copy-dt-needed-entries -L. -lt1 -v

/usr/lib64/gcc/x86_64-suse-linux/4.5/collect2 --build-id --eh-frame-hdr -m
elf_x86_64 -shared -o libt2.so
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/crti.o
/usr/lib64/gcc/x86_64-suse-linux/4.5/crtbeginS.o -L.
-L/usr/lib64/gcc/x86_64-suse-linux/4.5
-L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/lib
-L/usr/lib64/gcc/x86_64-suse-linux/4.5/../../.. --copy-dt-needed-entries -lt1
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib64/gcc/x86_64-suse-linux/4.5/crtendS.o
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib64/crtn.o

So, the --copy-dt-needed-entries argument is at the right place, right before
-lt1.  During my debugging I of course used this cmdline (well, substed
collect2 with the right ld).  Changing various options like removing libs
or the --as-needed doesn't make a difference for the behaviour we expect.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14590] New: ifunc problem: internal error, aborting at elf64-x86-64.c line 3175 in elf_x86_64_relocate_section

[matz at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=14590

 Bug #: 14590
   Summary: ifunc problem: internal error, aborting at
elf64-x86-64.c line 3175 in
elf_x86_64_relocate_section
   Product: binutils
   Version: 2.24 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: m...@suse.de
Classification: Unclassified


% cat x.c
#include stdio.h
int index;
int main() {
index=getchar();
return index;
}
% gcc -fno-builtin -static -g x.c
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: BFD
(GNU Binutils; devel:gcc / SLE-11) 2.22 internal error, aborting at
../../bfd/elf64-x86-64.c line 3094 in elf_x86_64_relocate_section

This is a problem also with older binutils.  This requires a libc which has
the symbol 'index' defined as weak ifunc:

18: 41 IFUNC   WEAK   DEFAULT1 index

It only happens when linking statically.  The abort is this one:

3170  bfd_vma plt_index;
3171  const char *name;
3172
3173  if ((input_section-flags  SEC_ALLOC) == 0
3174  || h-plt.offset == (bfd_vma) -1)
3175abort ();

The reference this is about is from .debug_info (i.e. !SEC_ALLOC), hence
the abort.  I don't know why it things it finds the ifunc definition
first (h-type is STT_GNU_IFUNC here), not the one in the COMMON section.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14590] ifunc problem: internal error, aborting at elf64-x86-64.c line 3175 in elf_x86_64_relocate_section

[matz at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=14590

Michael Matz matz at suse dot de changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14590] ifunc problem: internal error, aborting at elf64-x86-64.c line 3175 in elf_x86_64_relocate_section

[matz at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=14590

--- Comment #1 from Michael Matz matz at suse dot de 2012-09-17 15:31:45 UTC 
---
The problem seems to be specific to common symbols.  With -fno-common
it goes away.  The hash slot for the 'index' symbol get type STT_GNU_IFUNC
in elf_link_add_object_symbols when reading the libc.a symbol table,
even though it's only a weak def, and the slot referred to STT_OBJECT before.

We don't get a type-changed warning because type_change_ok is true.
I think we shouldn't regard weak defs to override common symbols.
But whatever we do, we must not segfault here, and preferrably still generate
expected code (as in, all references to index resolving to the common symbol).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/12772] symbols from discarded sections relocs stay

[matz at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=12772

Michael Matz matz at suse dot de changed:

   What|Removed |Added

 Status|WAITING |NEW

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/12772] symbols from discarded sections relocs stay

[matz at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=12772

Michael Matz matz at suse dot de changed:

   What|Removed |Added

Summary|relocations from discarded  |symbols from discarded
   |sections stay   |sections relocs stay

--- Comment #4 from Michael Matz matz at suse dot de 2011-05-18 11:54:22 UTC 
---
Yeah, sorry, my title was wrong.  The relocations really are gone.  But the
symbol table entry will stay, even though nothing refers to it anymore
(ultimately this then leads to libraries being included that aren't used
by anything).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/12772] New: relocations from discarded sections stay

[matz at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=12772

   Summary: relocations from discarded sections stay
   Product: binutils
   Version: 2.22 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
AssignedTo: unassig...@sources.redhat.com
ReportedBy: m...@suse.de


(this got initially reported into Novell bugzilla #694266).
Compile this with the following compile command on x86_64-linux:

# g++ -O3 -Wl,-gc-sections -fpic -shared \
-fdata-sections -ffunction-sections \
-fvisibility-inlines-hidden -fvisibility=hidden \
-o test.so test.cpp

# cat test.cpp
#include string.h
#include stdlib.h
#include unistd.h

extern C int __attribute__((visibility(default))) func(char *ptr)
{
static const char g_const[] = { 1, 1, 0 };
memcpy(ptr, g_const, 3);

return 0;
}

extern C char *func2(char *ptr)
{
static char buf[4096];
if (!getcwd(buf, sizeof(buf)))
buf[0] = 0;
#define STR test_string
memcpy(ptr, STR, sizeof(STR));
return buf;
}

Note that func2 will be hidden, and as it's unreferenced the .text.func2
section will be discarded, as will be the .bss._ZZ5func2E3buf section:

# ...
./ld/ld-new: Removing unused section '.text.func2' in file
'show-link-discard-fail.o'
./ld/ld-new: Removing unused section '.bss._ZZ5func2E3buf' in file
'show-link-discard-fail.o'

But the relocation to getcwd (or better it's default decorated variant
getcwd@@GLIBC_2.2.5) will stay and transferred into the output file.
It should have been discarded too.  In fact the gc_sweep_hook on x86_64
for instance does lower the PLT count for this reloc, and hence seems
to assume that it really won't be emitted.  But alas, it is.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/2342] linkonce debug is broken

[matz at suse dot de]

--- Additional Comments From matz at suse dot de  2006-04-24 14:33 ---
Btw, HJ: your patch to revert Alans also makes ld quite slow on huge 
testcases.  I put a tarball on http://www.suse.de/~gcctest/slowld.tar.gz . 
link command: 
 
% g++ -g -o ff3d trapFPE.o main.o FFThread.o StaticCenter.o  
language/libfflanguage.a solver/libffsolve.a language/libpovlanguage.a 
geometry/libffgeometry.a algebra/libffalgebra.a utils/libffutils.a -pthread 
 
This will take from five to ten minutes to link depending on the machine. 
These are i386 .o and .a files. 
 
The problem is that _bfd_elf_check_kept_section is N^2 in the number of 
sections, and furthermore does repeatedly the same work over and over again 
(e.g. sorting all symbols of a BFD over and over).  Not having PRETEND in 
action completely avoids this work here (though of course the N^2 problem 
still is there).  This reduces link time to about 2 to 3 seconds. 
 
We were trying to work-around this by noting that the 
_bfd_elf_check_kept_section() function basically is const, i.e. given 
the same discared input section it will give the same result every time. 
Hence we can remember it in struct bfd_section or in the ELF specific part 
of a section.  That still leavs multiple sorts over the same set of 
symbols for each BFD (one time for each section needing that handling). 
Then ld needs only 17 seconds, which still is much better. 
 
When I saw that this actually was not a problem in FSF binutils, but only 
in your version I stopped making the patch pretty for submission, so I  
add it here only for demonstration what I mean: 
 
-- 
@@ -7512,7 +7438,13 @@ elf_link_input_bfd (struct elf_final_lin 
{ 
  asection *kept; 
 
- kept = _bfd_elf_check_kept_section (sec); 
+ if (sec-hack_foo == NULL) 
+   { 
+ sec-hack_foo = _bfd_elf_check_kept_section 
(sec); 
+   } 
+ if (sec-hack_foo == NULL) 
+   sec-hack_foo = (void*)-1; 
+ kept = sec-hack_foo == (void*)-1 ? NULL : 
sec-hack_foo; 
  if (kept != NULL) 
{ 
  *ps = kept; 
- 
 
Probably can't be applied due to white-space changes.  Also add a 'hack_foo' 
member to asection ;-)  Perhaps you might use that idea in your reversal 
patch to make HJ binutils not as slow. 
 
Another thing I noticed while reading the code is some obvious funnyness 
in match_group_member(), which read like so: 
 
match_group_member (asection *sec, asection *group) 
{ 
  asection *first = elf_next_in_group (group); 
  asection *s = first; 
  while (s != NULL) 
{ 
  if (bfd_elf_match_symbols_in_sections (s, sec)) 
return s; 
  if (s == first) 
break; 
} 
  return NULL; 
} 
 
This obviously was designed to loop over all sections in a section group, 
when provided with one.  The loop structure and use of elf_next_in_group 
indicate this.  But this loop actually doesn't iterate, as s never 
is changed. 
 

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2342

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/2342] linkonce debug is broken

[matz at suse dot de]

--- Additional Comments From matz at suse dot de  2006-04-24 15:17 ---
10 minutes was the worst I think, with the tarball (it might be that it's 
not synced yet, I don't know how often the webserver does that). 

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2342

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils