[Bug ld/22831] ld causes massive thrashing if object files are not fully memory-resident: new algorithm needed

2018-03-15 Thread lkcl at lkcl dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=22831

--- Comment #15 from Luke Kenneth Casson Leighton  ---
(In reply to H.J. Lu from comment #14)
> (In reply to Luke Kenneth Casson Leighton from comment #13)
> >  i have 16 GB of DDR4 2400 mhz RAM on my laptop... and because when
> > that system goes into swap (it has an NVMe) its loadavg goes over 120
> > and it is absolutely guaranteed to crash about 30 seconds later,
> > adding more RAM is *not* the solution.
> > 
> >  however much more RAM is added, there *will* be a piece of software
> > within 1-5 years which requires more RAM for the linker phase than any
> > system provides.
> > 
> 
> Please try if "-Wl,--no-keep-memory" works.

i'll alert some people and see if they are in a position to try that.

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


[Bug ld/22962] [RISCV] add abi subdirectories support to ld

2018-03-15 Thread wilson at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=22962

--- Comment #11 from Jim Wilson  ---
(In reply to jos...@codesourcery.com from comment #10)
> Again, the quoted error is about a search that uses -rpath-link paths but 
> *not* -L paths.  GCC uses the right -L paths automatically, but 
> LIBPATH_SUFFIX settings in binutils are needed to get the right 
> -rpath-link paths used automatically.

Yes, I saw your message.  I hadn't missed it or forgotten about it.  I just
hadn't had time to respond to it yet, as it arrived too late in the day for me
to do anything with it.  Also, after missing a few days due to illness and a
home move, I have a large backlog of stuff to work on, and haven't gotten back
to this issue yet.

Meanwhile, I've been trying to summarize details that I had already found out
along the way, and details that have been discussed in other places that aren't
archived.

I'm also trying to understand why neither Fedora nor OpenSuse have run into
this problem.  Assuming it is glibc specific, then that explains why FreeBSD,
RTEMS, FreeRTOS, Zephyr, etc haven't hit the problem, as they likely aren't
using glibc and/or aren't using the same library scheme.  I know that there is
also a Debian port somewhere.  I'm not sure how far along they are, but they
apparently haven't hit this problem either.  So why has Serge hit it?

I'm also trying to understand the problem as best as I can before making any
change, as I want to avoid breaking any of the existing systems which are all
working with the current linker support.  That includes systems using the
upstream glibc and systems using the pre-upstream glibc, which may be using
different library directory conventions.

-- 
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/22962] [RISCV] add abi subdirectories support to ld

2018-03-15 Thread joseph at codesourcery dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=22962

--- Comment #10 from joseph at codesourcery dot com  ---
Again, the quoted error is about a search that uses -rpath-link paths but 
*not* -L paths.  GCC uses the right -L paths automatically, but 
LIBPATH_SUFFIX settings in binutils are needed to get the right 
-rpath-link paths used automatically.

-- 
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/22972] [SPARC] Mixing GOT and GOTDATA_OP relocations can lead to broken binaries

2018-03-15 Thread ebotcazou at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=22972

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at sourceware dot org   |ebotcazou at gcc dot 
gnu.org
   Target Milestone|--- |2.31

--- Comment #3 from Eric Botcazou  ---
Fixing.

-- 
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/22972] [SPARC] Mixing GOT and GOTDATA_OP relocations can lead to broken binaries

2018-03-15 Thread jrtc27 at jrtc27 dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=22972

--- Comment #2 from James Clarke  ---
They come from hand-written assembly. Of course that can be modernised, but
that doesn’t solve the problem; there are a surprising number of projects out
there with hand-written SPARC assembly, and currently LLVM only generates the
old relocations.

-- 
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/22967] nm should distinguish in between local and global ifunc

2018-03-15 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=22967

Nick Clifton  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #5 from Nick Clifton  ---
Hi Martin,

> I probably incline to 3).

Actually I think that we can accommodate all three alternatives...

Imagine that there is a configure-time option to set the default
behaviour, then we add a new command line option to nm called
--ifunc-chars that behaves as follows:

  --ifunc-chars= 
   Restores default behaviour - however that was configured.

  --ifunc-chars=
   Use  for both local and global ifuncs.
   It is the user's responsibility to choose a  that does not
conflict

  --ifunc-chars=
   Use  for global ifuncs.  
   Use  for local ifuncs.
   It is the user's responsibility to choose s that do not conflict.

   --ifunc-chars=
   Use  for global ifuncs.  
   Use  for local ifuncs.
   Use  for indirect symbols.
   It is the user's responsibility to choose s that do not conflict.

Maybe nm should warn if a  is chosen that conflicts with another symbol
type...

I'll try to run up a patch that implements this idea, although I must admit
that
this PR does have a low priority at the moment ...

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 ld/22949] ld: --relax and -r may not be used together

2018-03-15 Thread sch...@linux-m68k.org
https://sourceware.org/bugzilla/show_bug.cgi?id=22949

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #2 from Andreas Schwab  ---
Fixed in 2.31.

-- 
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/22949] ld: --relax and -r may not be used together

2018-03-15 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=22949

--- Comment #1 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Andreas Schwab :

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

commit 202d116e5714a0c21d0c38b7dd45b5d4ee494880
Author: Andreas Schwab 
Date:   Sun Mar 11 14:25:30 2018 +0100

RISC-V: Don't enable relaxation in relocatable link

PR ld/22949
* emultempl/riscvelf.em (riscv_elf_before_allocation): Don't
enable relaxation in relocatable link.

-- 
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/22962] [RISCV] add abi subdirectories support to ld

2018-03-15 Thread david.abdurachmanov at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=22962

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

-- 
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/22972] [SPARC] Mixing GOT and GOTDATA_OP relocations can lead to broken binaries

2018-03-15 Thread ebotcazou at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=22972

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-15
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Where do the older R_SPARC_GOT22/10 relocations come from for OpenSSL?

-- 
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/22962] [RISCV] add abi subdirectories support to ld

2018-03-15 Thread belyshev at depni dot sinp.msu.ru
https://sourceware.org/bugzilla/show_bug.cgi?id=22962

--- Comment #9 from Serge Belyshev  ---
(In reply to Jim Wilson from comment #8)
> If gcc is configured --enable-multilib, then it appears that you get the -L
> options you need for this to work.  If gcc is configured --disable-multilib,
> then you do not get the -L options needed for this to work.
> 
> Is your gcc configured --disable-multilib?

Indeed my gcc configured with --disable-multilib.

Hovewer, I see that relevant directories appear in the LIBRARY_PATH and thus on
the ld command line.  And moreover, adding -L/lib64/lp64d   manually on gcc
command line does not fix the problem.  See relevalnt parts of the output:

$ gcc f2.c -o f2   -L/lib64/lp64d -L/usr/lib64/lp64d f1.so  -v -Wl,--verbose
...
LIBRARY_PATH=/usr/lib/gcc/riscv64-unknown-linux-gnu/7.3.1/:/usr/lib/gcc/riscv64-unknown-linux-gnu/7.3.1/../../../../riscv64-unknown-linux-gnu/lib/:/lib64/lp64d/:/usr/lib64/lp64d/:/lib/:/usr/lib/
...
/usr/libexec/gcc/riscv64-unknown-linux-gnu/7.3.1/collect2 -plugin
/usr/libexec/gcc/riscv64-unknown-linux-gnu/7.3.1/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/riscv64-unknown-linux-gnu/7.3.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc0RVYrX.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
--eh-frame-hdr -melf64lriscv -dynamic-linker /lib/ld-linux-riscv64-lp64d.so.1
-o f2 /usr/lib64/lp64d/crt1.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/7.3.1/crti.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/7.3.1/crtbegin.o
-L/usr/lib/gcc/riscv64-unknown-linux-gnu/7.3.1
-L/usr/lib/gcc/riscv64-unknown-linux-gnu/7.3.1/../../../../riscv64-unknown-linux-gnu/lib
-L/lib64/lp64d -L/usr/lib64/lp64d /tmp/ccYKxfmX.o f1.so --verbose -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/riscv64-unknown-linux-gnu/7.3.1/crtend.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/7.3.1/crtn.o
...
SEARCH_DIR("/usr/riscv64-unknown-linux-gnu/lib64");
SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64");
SEARCH_DIR("/usr/riscv64-unknown-linux-gnu/lib"); SEARCH_DIR("/usr/local/lib");
SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
...
/usr/lib/gcc/riscv64-unknown-linux-gnu/7.3.1/../../../../riscv64-unknown-linux-gnu/bin/ld:
warning: libm.so.6, needed by f1.so, not found (try using -rpath or
-rpath-link)

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