[PATCH v3] ld: Maintain the input file order

[H.J. Lu]

On Thu, Apr 23, 2026 at 10:39 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Apr 23, 2026 at 10:33 AM Alan Modra <amodra@gmail.com> wrote:
> >
> > On Thu, Apr 23, 2026 at 09:04:43AM +0800, H.J. Lu wrote:
> > > My patch only changes the real input file order, not the other
> > > traversing orders:
> >
> > Yes, that was what I was flagging as a possible defect.  I don't think
> > lang_input_statement_type.next is a problem, but header.next may well
> > be.  Many places traverse that list.
>
> Without my change in new_afile, before new_afile returns:
>
> 1315     lang_statement_append (&input_file_chain, p, &p->next_real_file);
>
>                ^^^^^^^^^^^^^ Only next_real_file is chained.
> (gdb) p *p
> $4 = {header = {next = 0x0, type = lang_input_statement_enum},
>                      ^^^^^^^^ header.next  == NULL
>   filename = 0x715770 "/usr/lib64/libm-2.42.a",
>   local_sym_name = 0x715770 "/usr/lib64/libm-2.42.a", sort_key = 0x0,
>   extra_search_path = 0x0, the_bfd = 0x0, the_ctf = 0x0,
>   section_flag_list = 0x0, next = 0x0, next_real_file = 0x0, target = 0x0,
>                                        ^^^^^^^^^ next == NULL
>   flags = {maybe_archive = 0, full_name_provided = 0, search_dirs = 1,
>     sysrooted = 0, just_syms = 0, dynamic = 0, add_DT_NEEDED_for_dynamic = 0,
>     add_DT_NEEDED_for_regular = 0, whole_archive = 0, link_mapless = 1,
>     fake_archive = 0, loaded = 0, member = 0, real = 1, missing_file = 0,
>     reload = 0, claimed = 0, claim_archive = 0, lto_output = 0, pushed = 0x0}}
> (gdb)
>
> > > Do you have a test to show my patch is wrong?
> >
> > No.  I didn't even try to analyse where things may go wrong, sorry.
> >
> > Hmm, if you generate a linker map file you can see that although libm
> > appears before libc on the linker command file, libc object sections
> > appear before libm object sections.  I haven't checked, but you might
> > like to verify that library dependencies work.  ie. in this case that
> > an object in libm-2.42.a with a dependency on a libc.a object will
> > cause the libc.a object to be extracted.
> >
>
> I will check.
>

It works correctly:

[hjl@gnu-tgl-3 pr34088]$ cat x.c
#include <fenv.h>

int
main (void)
{
  feclearexcept (FE_ALL_EXCEPT);
  return 0;
}
[hjl@gnu-tgl-3 pr34088]$ cat m.c
#include <stdio.h>

int
feclearexcept (int i)
{
  printf ("PASS: 0x%x\n", i);
}
[hjl@gnu-tgl-3 pr34088]$ make
gcc -B./ -flto   -c -o x.o x.c
gcc -B./ -O0   -c -o m.o m.c
ar -rv libdummy.a m.o
ar: creating libdummy.a
a - m.o
echo "GROUP (libdummy.a)" > libdummy-m.a
gcc -B./ -static -o x x.o libdummy-m.a
./x
PASS: 0x3d
rm m.o
[hjl@gnu-tgl-3 pr34088]$ gcc -B./ -static -o x x.o  libdummy-m.a
-Wl,-y,printf,-y,feclearexcept
/export/build/gnu/tools-build/binutils-gitlab/build-x86_64-linux/ld/ld-new:
/tmp/cc6Ghl8I.ltrans0.ltrans.o: reference to feclearexcept
/export/build/gnu/tools-build/binutils-gitlab/build-x86_64-linux/ld/ld-new:
./libdummy.a(m.o): definition of feclearexcept
/export/build/gnu/tools-build/binutils-gitlab/build-x86_64-linux/ld/ld-new:
./libdummy.a(m.o): reference to printf
/export/build/gnu/tools-build/binutils-gitlab/build-x86_64-linux/ld/ld-new:
/usr/lib/gcc/x86_64-redhat-linux/15/../../../../lib64/libc.a(printf.o):
definition of printf
[hjl@gnu-tgl-3 pr34088]$


-- 
H.J.