Re: Can gold's max page size for AArch64 be updated to 64k to match current kernel capabilities?

[Andreas Schwab]

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Bug binutils/19054] New: wrong assembly and disassembly for fsubp/fsubrp

[mattiase at acm dot org]

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

Bug ID: 19054
   Summary: wrong assembly and disassembly for fsubp/fsubrp
   Product: binutils
   Version: 2.25
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: mattiase at acm dot org
  Target Milestone: ---

The x86 (x87) instructions fsubp and fsubrp seem to be swapped both in assembly
and disassembly. The assembly source:

fsubp %st, %st(5)
fsubrp %st, %st(5)

results in the following, after going through as and objdump:

   0:   de e5   fsubp  %st,%st(5)
   2:   de ed   fsubrp %st,%st(5)

However, according to the architecture reference (and Intel's XED tool), [de
ed] is fsubp and [de e5] fsubrp, so the "r" bit seems to have been flipped in
both as and objdump. For instance, XED on the same file outputs

XDIS 0: X87_ALU   X87DEE5 fsubrp st5, st0
XDIS 2: X87_ALU   X87DEED fsubp st5, st0

The binutils error does not depend on whether AT&T or Intel syntax is used.

-- 
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/19030] ld generates .so/x86 with bad phdr so the Android linker won't dlopen

[winter-...@bfw-online.de]

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

--- Comment #5 from winter-...@bfw-online.de ---
> Yes, one dash or two makes a difference.

Using single-dash arguments can then be considered pretty dangerous in ld since
any small typo (or using a parameter that might only exist in some other ld
version) in the argument results in ld looking for single letter arguments
(even in concatenation) which it almost always find.

$ ld -nostdlib # correct
$ ld -nostdllib # incorrect, results in -n -o stdllib

Much safer is double dash:

$ ld --nostdlib # correct
$ ld --nostdllib
ld: unrecognized option '--nostdllib'

I figure a lot of people and application rely on single letter concatenation
like this, but probably also a lot of people suffer from incorrectly applied
settings without even knowing.

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

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

[Bug binutils/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
Hi John,

  Please could you upload the libsystemd.so file so that I can examine it ?

  It seems strange that this problem has only recently arisen, as the code that
checks STT_REGISTER and issues the error message has been in the binutils since
1999.

  It is also not clear to me if the error message is correct.  Looking the
version 2.4.1 of the Sparc Compliance Definition document (which is the latest
version I could find), the only restriction appears to be that the STT_REGISTER
symbol should refer to an integer register.  I am not a SPARC expert however,
so if you know more about the ABI, please let me know.

Cheers
  Nick

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

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

[Bug binutils/19054] wrong assembly and disassembly for fsubp/fsubrp

[mattiase at acm dot org]

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

Mattias Engdegård  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Mattias Engdegård  ---
Sorry, this is apparently a long-known problem that cannot be solved easily
since the code generator in GCC and other compilers rely on it. Using
intel-mnemonic makes the problem go away.

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

[Bug binutils/19055] New: 2.25 regression: strip unable to rename; reason: File exists

[rai...@emrich-ebersheim.de]

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

Bug ID: 19055
   Summary: 2.25 regression: strip unable to rename; reason: File
exists
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: rai...@emrich-ebersheim.de
  Target Milestone: ---

That's on an msys setup targeting x86_64-w64-mingw32.

$ strip --version
GNU strip (GNU Binutils) 2.25
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

$ strip --strip-unneeded foo.dll
strip.exe: unable to rename 'foo.dll'; reason: File exists

This works for binutils-2.24!

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

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

[Bug binutils/19055] 2.25 regression: strip unable to rename; reason: File exists

[rai...@emrich-ebersheim.de]

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

Rainer Emrich  changed:

   What|Removed |Added

 Target||x86_64-w64-mingw32
   Host||x86_64-w64-mingw32
Version|unspecified |2.25
  Build||x86_64-w64-mingw32

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

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

[Bug binutils/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd

[fberckel at xs4all dot nl]

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

Frans van Berckel  changed:

   What|Removed |Added

 CC||fberckel at xs4all dot nl

--- Comment #2 from Frans van Berckel  ---
Created attachment 8671
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8671&action=edit
libsystemd0_226-3_sparc64

File: /lib/sparc64-linux-gnu/libsystemd.so.0.11.0
Extracted: libsystemd0_226-3_sparc64.deb
Origin: https://packages.debian.org/sid/sparc64/libsystemd0/download
Zip: by gzip < libsystemd.so.0.11.0 >libsystemd.so.0.11.0.gz

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

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

[Bug binutils/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd

[jose.marchesi at oracle dot com]

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

Jose E. Marchesi  changed:

   What|Removed |Added

 CC||jose.marchesi at oracle dot com

--- Comment #3 from Jose E. Marchesi  ---
The SCD in page 4P-3 declares that the purpose of STT_SPARC_REGISTER is to
indicate the "Usage of a global register reserved by the application" and,
optionally, global registers reserved for system software.  The subset of
global registers reserved for applications is defined in page 3P-10 as %g2 and
%g3.  Likewise, the subset of global registers reserved for system software is
defined in the same table.

So I think that the BFD check is pertinent and matches the ABI.

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

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

[Bug binutils/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd

[jose.marchesi at oracle dot com]

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

--- Comment #4 from Jose E. Marchesi  ---
$ readelf -s libsystemd.so.0.11.0
[...]
   617:  0 REGISTER GLOBAL DEFAULT  UND

There it is... st_value is 0.  How was this library linked, exactly?  I tried
to build systemd 226 in my non-Debian sparc64 system, but gave up due to many
build errors...

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

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

[Bug binutils/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from glaubitz at physik dot fu-berlin.de  ---
Hi Jose!

(In reply to Jose E. Marchesi from comment #3)
> So I think that the BFD check is pertinent and matches the ABI.

Thank you very much for the analysis!

So you'd say that this is indeed not a bug in binutils but gcc?

If yes, I will try to pinpoint the gcc version which introduced the issue.

I know, for fact, that systemd_215-5 does not have this isssue.

@Frans: Could you fetch systemd_215-5 for sparc64 from snapshots.debian.org and
extract libsystemd.so from it to attach it to this bug tracker? I'm currently
sitting at the airport on my way to Japan and I only have my phone at the
moment.

systemd_215-5 was compiled with gcc-4.9 while 226-3 was compiled with gcc-5, so
it might be a regression introduced with gcc-5.

Again, thanks everyone for the help so far. I am currently working to bring
Debian's sparc ports (both 32- and 64-bit), and I need your help to resolve any
toolchain issues first.

Adrian

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

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

[Bug binutils/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd

[jose.marchesi at oracle dot com]

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

--- Comment #6 from Jose E. Marchesi  ---
This could still be a bug in either binutils or GCC.  However, I have
bootstrapped GCC 5 (also svn trunk GCC) with the latest binutils in sparc64 and
have never seen this issue.

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

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

[Bug binutils/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd

[fberckel at xs4all dot nl]

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

--- Comment #7 from Frans van Berckel  ---
Created attachment 8673
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8673&action=edit
libsystemd.so.0.3.1

File: /lib/sparc64-linux-gnu/libsystemd.so.0.3.1
Extracted: libsystemd0_215-5_sparc64.deb
Origin:
http://snapshot.debian.org/archive/debian-ports/20150101T014653Z/pool-sparc64/main/s/systemd/
Zip: by gzip < libsystemd.so.0.3.1 >libsystemd.so.0.3.1.gz

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

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

[Bug binutils/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd

[jose.marchesi at oracle dot com]

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

--- Comment #8 from Jose E. Marchesi  ---
libsystemd.so.0.3.1 contains the expected STT_SPARC_REGISTER entries, for %g2
and %g3:

 4: 0002 0 REGISTER GLOBAL DEFAULT  UND
 5: 0003 0 REGISTER GLOBAL DEFAULT  UND

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

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

[Bug gold/18855] String constants mixed up when linked with gold on Linux/sparc64

[sourceware-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

Michael Karcher  
changed:

   What|Removed |Added

 CC||sourceware-bugzilla@mkarche
   ||r.dialup.fu-berlin.de

--- Comment #5 from Michael Karcher  ---
Created attachment 8675
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8675&action=edit
Automated testcase

I made a automatic test case for it (see attachment). I think the ltrans.*.s
file in my archive are my own gcc invocation on sparc64, but the files from
attachment 8619 should do as well. Just run make from the attached archive,
after extracting it into a binutils build tree:

mkarcher@aquila:~/src/Development/binutils-gdb/testdata$ make -s clean check
First output line: address that gets passed to puts
Second output line: address that contains the string to be printed
 142c00 2025730a  252d3673 5b256c69   %s.%-6s[%li
 1428d0 32323600  3d3d3d20 74726965  226.=== trie
mkarcher@aquila:~/src/Development/binutils-gdb/testdata$ make -s clean check
LD=../ld/ld-new
../ld/ld-new: warning: cannot find entry symbol _start; defaulting to
00100120
First output line: address that gets passed to puts
Second output line: address that contains the string to be printed
 1428b0 6e00  32323600   n...226.
 1428b0 6e00  32323600   n...226.

Using ld, the output is OK (the same line is outputted twice), using gold (the
default), the output shows that the string reference is off. The testcase is
host platform independent, it just requires binutils to be compiled for target
architecture sparc64-unknown-linux-gnu.

Interestingly, the output from gold has been observed to be correct for some
orders of the object files, but incorrect for other orders (happened to me
until I had sorting in, as the file names got mixed up as the kernel liked
depending on what files were present in the same directory).

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

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

[Bug gold/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd

[sourceware-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

Michael Karcher  
changed:

   What|Removed |Added

 CC||ian at airs dot com,
   ||sourceware-bugzilla@mkarche
   ||r.dialup.fu-berlin.de
  Component|binutils|gold
   Assignee|unassigned at sourceware dot org   |ccoutant at gmail dot 
com

--- Comment #9 from Michael Karcher  ---
With access to a Debian build box, I found out that the broken shared library
is created by LTO-linking with gold. The invocation is basically the following
gcc command.

gcc -shared -fPIC $(OBJECTS) -flto -O2 -Wl,--gc-sections -Wl,--as-needed -Wl,-z
-Wl,relro -Wl,-z -Wl,now -Wl,-fuse-ld=gold
-Wl,--version-script=../src/libsystemd/libsystemd.sym -Wl,-z -Wl,relro  
-pthread -Wl,-soname -Wl,libsystemd.so.0 -o .libs/libsystemd.so.0.11.0

If I omit "-Wl,-fuse-ld=gold", I obtain a correct libsystemd.so.0.11.0:

$ readelf -s .libs/libsystemd.so.0.11.0  | grep REGISTER
 4: 0002 0 REGISTER GLOBAL DEFAULT  UND 
 5: 0003 0 REGISTER GLOBAL DEFAULT  UND 
  2007: 0002 0 REGISTER GLOBAL DEFAULT  UND 
  2008: 0003 0 REGISTER GLOBAL DEFAULT  UND 

Using gcc --save-temps, I obtained the LTO-generated assembler files, assembled
them using

as -s -K PIC -Av9 -64 -no-undeclared-regs -relax -o $x.o $x

objdumping those files shows only REGISTER declarations for %g2 and %g3, which
seem fine, linking them with gold results in a broken output file. I will
attach the object files.

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

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

[Bug gold/19019] [SPARC64] Only registers %g[2367] can be declared using STT_REGISTER when linking against libsystemd

[sourceware-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

--- Comment #10 from Michael Karcher  ---
Created attachment 8676
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8676&action=edit
machine object files created during LTO link

Attached: seemingly correct object files resulting in the broken shared object.

(sid-sparc64-sbuild)mkarcher@ravirin:~/systemd-226/build-deb$ for x in
libsystemd.so.0.11.0.ltrans*.s.o; do readelf -s $x | grep REGISTER ; done 
65: 0002 0 REGISTER GLOBAL DEFAULT  UND 
66: 0003 0 REGISTER GLOBAL DEFAULT  UND 
[...]
27: 0002 0 REGISTER GLOBAL DEFAULT  UND 
28: 0003 0 REGISTER GLOBAL DEFAULT  UND 
(sid-sparc64-sbuild)mkarcher@ravirin:~/systemd-226/build-deb$ gold -shared
lib*ltrans*s.o -o temp.so
(sid-sparc64-sbuild)mkarcher@ravirin:~/systemd-226/build-deb$ readelf -s
temp.so  | grep REGISTER
  1379:  0 REGISTER GLOBAL DEFAULT  UND 
(sid-sparc64-sbuild)mkarcher@ravirin:~/systemd-226/build-deb$ tar -cvjf
intermediates.tar.bz2 lib*ltrans*.s.o

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

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