[PATCH v3] ld: Maintain the input file order

[H.J. Lu]

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.


-- 
H.J.