Re: [PATCH] ld: Check bfd_gc_sections return

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.

-- 
H.J.