Re: [PATCH] ld: Check bfd_gc_sections return

On Thu, Aug 06, 2026 at 05:24:14AM +0800, H.J. Lu wrote:
> On Wed, Aug 5, 2026 at 6:40 PM Jan Beulich <[email protected]> wrote:
> >
> > On 05.08.2026 12:32, H.J. Lu wrote:
> > > On Wed, Aug 5, 2026 at 4:59 PM Jan Beulich <[email protected]> wrote:
> > >>
> > >> On 05.08.2026 10:50, H.J. Lu wrote:
> > >>> bfd_gc_sections may return false on invalid input:
> > >>>
> > >>> ld: pr34448-bug_18.o: bad reloc symbol index (0xf2000005 >= 0x13) for
> > >>> offset 0x4 in section `.text.get_tls[get_tls]'
> > >>>
> > >>> and set the BFD error to bfd_error_bad_value.  Check bfd_gc_sections
> > >>> return and report the fatal error if the BFD error is bfd_error_bad_value.
> > >>
> > >> And what guarantees that bfd_error_bad_value isn't also set for other kinds
> > >> of errors, from about anywhere in the library? Does bfd_gc_sections()
> > >> returning false even reliably set the error indicator? That's far from
> > >
> > > If it isn't the case, it is a bug.
> > >
> > >> obvious when looking at e.g. bfd_elf_gc_sections(), so I can't exclude the
> > >> possibility of bfd_error_bad_value having been on record before the call,
> > >> and it simply not getting changed.
> > >
> > > Isn't it a bug?
> >
> > I don't know, as I don't know enough of the history of libbfd. The value could
> > be meant to be errno-like, i.e. you may need to clear it at certain points
> > (especially if there's a mix of functions storing into and not storing into
> > the field).
> 
> When a bfd function returns an error, the BFD error should be set
> appropriately.  If it isn't the case, it is a BFD bug.

The original commits 303b4cc64fa8 and 71b012a810fd omitted
checking the return from bfd_gc_sections, but I'm inclined to think
that any false return from bfd_gc_sections should result in an error
exit from ld, displaying the bfd error with %E.  We also should not be
ignoring a false return from gc_mark_extra_sections in
bfd_elf_gc_sections.

-- 
Alan Modra