Why GROUP(...) rather than INPUT(...) is used here?

[rednoah <rednoax@163.com>]

[-- Attachment #1: Type: text/plain, Size: 3747 bytes --]


Hi all:
If adding -v in gcc linking process for a simple m.c building, it shows -lgcc_s
is used during link:
$ gcc -v m.c -Wl,-t
....
 /usr/lib/gcc/x86_64-linux-gnu/9/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/9/liblto_plugin.so
 -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper -plugin-opt=-fresolution=/tmp/cccTnaHb.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 --build-id --eh-frame-hdr -m elf_x86_64
 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro
 /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o
 /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o
 /usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/9
 -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib
 -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/9/../../..
 /tmp/ccYxryTe.o -t -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s
 --pop-state /usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crtn.o
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o
/tmp/ccYxryTe.o
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a <= libgcc.a is processed for the 1st time
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a <= libgcc.a is processed for the 2nd time
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libc.so
...
the "-Wl,-t" output shows libgcc.a is processed twice as marked above.

on ubuntu 20.04, libgcc_s.so is actually a script.
$ cat  /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library.  */
GROUP ( libgcc_s.so.1 -lgcc )

The "-lgcc" linked here is actually libgcc.a. "libgcc_s.so.1" is an elf
shared object so there is only one archive file "libgcc.a" in GROUP(...).
GROUP(...) equals to "--start-group ... --end-group" and it is to enclose
two or more archive files to search undefined symbols repeatedly. There
seems no need to uss it when there is only one archive file in it. Maybe
INPUT(...) is a better choice here?

To verify it I write some toy .c, there seems no problem:
m.c:
int _start(){
    return b1();
}
b0.c:
int b0() {
    return 0;
}
b1.c:
int b1() {
    return b0();
}
$ gcc -c -fpic *.c
$ ar rcs b.a b0.o b1.o <=b0.o is in front of b1.o
$ gcc -nostdlib -Wl,-t,-Map=1.map,-verbose m.o b.a
......
/usr/bin/ld: mode elf_x86_64
attempt to open m.o succeeded
m.o
attempt to open b.a succeeded
b.a
(b.a)b1.o
(b.a)b0.o

In archive b.a, b0.o is in front of b1.o. b1.o has reference to
b0 in b0.o. Although b.a is processed only once, no any error. I
guess it may be achieved by the archive index, which contains all
symbols of each .o in b.a.

The following is to emulate the afront mentioned gcc's way, the
m.o and b.a are enclosed by --start/end-group:
$ gcc -nostdlib -Wl,-t,-Map=1.map,-verbose '-Wl,-(' m.o b.a '-Wl,-)'
...
/usr/bin/ld: mode elf_x86_64
attempt to open m.o succeeded
m.o
attempt to open b.a succeeded
b.a
(b.a)b1.o
(b.a)b0.o
b.a

No error and b.a is proccessed twice, just like libgcc.a is
processed twice.
Could anyone help explain why libgcc_s.so script use GROUP(...)
for only one archive: GROUP ( libgcc_s.so.1 -lgcc ).
Can it be replaced with INPUT(...)?

Thanks