public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug lto/105133] New: lto/gold: lto failed to link --start-lib/--end-lib in gold
@ 2022-04-02  2:17 luoxhu at gcc dot gnu.org
  2022-04-04  7:07 ` [Bug lto/105133] lto/gold: lto failed to link --start-lib/--end-lib in gold for duplicate libraries rguenth at gcc dot gnu.org
  2022-04-06  4:54 ` luoxhu at gcc dot gnu.org
  0 siblings, 2 replies; 3+ messages in thread
From: luoxhu at gcc dot gnu.org @ 2022-04-02  2:17 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105133

            Bug ID: 105133
           Summary: lto/gold: lto failed to link --start-lib/--end-lib in
                    gold
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: luoxhu at gcc dot gnu.org
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi, linker gold supports --start-lib and --end-lib to "mimics the
semantics of static libraries, but without needing to actually create
the archive file."(https://reviews.llvm.org/D66848).  Sometimes large
application may introduce multiple libraries from different repositories with
same source code, they would be linked into one binary finally, recently I
suffered from a link error with gold as linker and reduced an example as below:

cat hello.c
extern int hello(int a);
int main(void)
{
  return 0; /* hello(10); */
}

cat ./B/libhello.c
#include <stdio.h>
int hello(int a)
{
   puts("Hello");
   return 0;
}

cat ./C/libhello.c
#include <stdio.h>
int hello(int a)
{
   puts("Hello");
   return 0;
}


(1) NON lto link with gold is OK:

gcc -O2 -o ./B/libhello.c.o   -c ./B/libhello.c
gcc-ar qc ./B/libhello.a  ./B/libhello.c.o
gcc-ranlib ./B/libhello.a
gcc -O2 -o ./C/libhello.c.o   -c ./C/libhello.c
gcc-ar qc ./C/libhello.a  ./C/libhello.c.o
gcc-ranlib ./C/libhello.a
gcc hello.c -o hello.o -c -O2
gcc -o hellow hello.o -Wl,--start-lib ./B/libhello.c.o  -Wl,--end-lib
-Wl,--start-lib ./C/libhello.c.o -Wl,--end-lib -O2 -fuse-ld=gold


(2) lto link with gold fails with redefinition:
gcc -O2 -flto  -o ./B/libhello.c.o   -c ./B/libhello.c
gcc-ar qc ./B/libhello.a  ./B/libhello.c.o
gcc-ranlib ./B/libhello.a
gcc -O2 -flto  -o ./C/libhello.c.o   -c ./C/libhello.c
gcc-ar qc ./C/libhello.a  ./C/libhello.c.o
gcc-ranlib ./C/libhello.a
gcc hello.c -o hello.o -c -O2 -flto
gcc -o hellow hello.o -Wl,--start-lib ./B/libhello.c.o  -Wl,--end-lib
-Wl,--start-lib ./C/libhello.c.o -Wl,--end-lib -O2 -flto -fuse-ld=gold


./B/libhello.c:5:5: error: 'hello' has already been defined
    5 | int hello(int a)
      |     ^
./B/libhello.c:5:5: note: previously defined here
lto1: fatal error: errors during merging of translation units
compilation terminated.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld.gold: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

This error happens at function gcc/lto/lto-symtab.c:lto_symtab_resolve_symbols,
simply remove the error_at line could work, but this may be not a reasonable
fix.  

  /* Find the single non-replaceable prevailing symbol and
     diagnose ODR violations.  */
  for (e = first; e; e = e->next_sharing_asm_name)
    {
      if (!lto_symtab_resolve_can_prevail_p (e))
        continue;

      /* If we have a non-replaceable definition it prevails.  */
      if (!lto_symtab_resolve_replaceable_p (e))
        {
          if (prevailing)
            {
              error_at (DECL_SOURCE_LOCATION (e->decl),
                        "%qD has already been defined", e->decl);
              inform (DECL_SOURCE_LOCATION (prevailing->decl),
                      "previously defined here");
            }
          prevailing = e;
        }
    }


cat hellow.res
3
hello.o 2
192 ccb9165e03755470 PREVAILING_DEF main
197 ccb9165e03755470 PREVAILING_DEF_IRONLY s
./B/libhello.c.o 1
205 68e0b97e93a52d7a PREEMPTED_REG hello
./C/libhello.c.o 1
205 18fe2d3482bfb511 PREEMPTED_REG hello


Secondly, If call hello(10) in hello.c , there will be NO error reported out.
The difference is the resolution type is changed from PREEMPTED_REG to
RESOLVED_IR/PREVAILING_DEF_IRONLY.  

3
hello.o 3
192 19ef867d12f62129 PREVAILING_DEF main
197 19ef867d12f62129 PREVAILING_DEF_IRONLY s
201 19ef867d12f62129 RESOLVED_IR hello
./B/libhello.c.o 1
205 23c5c855935478ce PREVAILING_DEF_IRONLY hello
./C/libhello.c.o 1
205 abbf050f5c23b448 PREEMPTED_REG hello


Is this a valid bug? Thanks.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug lto/105133] lto/gold: lto failed to link --start-lib/--end-lib in gold for duplicate libraries
  2022-04-02  2:17 [Bug lto/105133] New: lto/gold: lto failed to link --start-lib/--end-lib in gold luoxhu at gcc dot gnu.org
@ 2022-04-04  7:07 ` rguenth at gcc dot gnu.org
  2022-04-06  4:54 ` luoxhu at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-04-04  7:07 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105133

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ccoutant at gmail dot com,
                   |                            |iant at google dot com

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to luoxhu from comment #0)
> 
> cat hellow.res
> 3
> hello.o 2
> 192 ccb9165e03755470 PREVAILING_DEF main
> 197 ccb9165e03755470 PREVAILING_DEF_IRONLY s
> ./B/libhello.c.o 1
> 205 68e0b97e93a52d7a PREEMPTED_REG hello
> ./C/libhello.c.o 1
> 205 18fe2d3482bfb511 PREEMPTED_REG hello

This looks like a gold bug - we have 'hello' pre-empted twice but no prevailing
symbol in the IR - are you ending up with fat LTO objects?

OTOH PREEMPTED_REG seems then handled wrongly by LTO as well - it should
throw away both copies since the linker told us it found a preempting
definition in a non-IR object file.  So I'd expect a unresolved reference
to 'hello' rather than LTO complaining about multiple definitions ...

Note gold is really unmaintained, so you should probably avoid using it.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug lto/105133] lto/gold: lto failed to link --start-lib/--end-lib in gold for duplicate libraries
  2022-04-02  2:17 [Bug lto/105133] New: lto/gold: lto failed to link --start-lib/--end-lib in gold luoxhu at gcc dot gnu.org
  2022-04-04  7:07 ` [Bug lto/105133] lto/gold: lto failed to link --start-lib/--end-lib in gold for duplicate libraries rguenth at gcc dot gnu.org
@ 2022-04-06  4:54 ` luoxhu at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: luoxhu at gcc dot gnu.org @ 2022-04-06  4:54 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105133

--- Comment #2 from luoxhu at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> (In reply to luoxhu from comment #0)
> > 
> > cat hellow.res
> > 3
> > hello.o 2
> > 192 ccb9165e03755470 PREVAILING_DEF main
> > 197 ccb9165e03755470 PREVAILING_DEF_IRONLY s
> > ./B/libhello.c.o 1
> > 205 68e0b97e93a52d7a PREEMPTED_REG hello
> > ./C/libhello.c.o 1
> > 205 18fe2d3482bfb511 PREEMPTED_REG hello
> 
> This looks like a gold bug - we have 'hello' pre-empted twice but no
> prevailing
> symbol in the IR - are you ending up with fat LTO objects?

It is not fat LTO objects since I didn't add -ffat-lto-objects when generating
lib:

nm libhello.a

libhello.c.o:
nm: libhello.c.o: plugin needed to handle lto object
0000000000000001 C __gnu_lto_slim


> 
> OTOH PREEMPTED_REG seems then handled wrongly by LTO as well - it should
> throw away both copies since the linker told us it found a preempting
> definition in a non-IR object file.  So I'd expect a unresolved reference
> to 'hello' rather than LTO complaining about multiple definitions ...

Will you fix it? :)

> 
> Note gold is really unmaintained, so you should probably avoid using it.

Thanks. Will try lld instead.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-04-06  4:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-02  2:17 [Bug lto/105133] New: lto/gold: lto failed to link --start-lib/--end-lib in gold luoxhu at gcc dot gnu.org
2022-04-04  7:07 ` [Bug lto/105133] lto/gold: lto failed to link --start-lib/--end-lib in gold for duplicate libraries rguenth at gcc dot gnu.org
2022-04-06  4:54 ` luoxhu at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).