[PATCH] ld: Fix segfault in populate_publics_stream

[Jan Beulich]

On 28.11.2022 18:53, Mark Harmstone wrote:
>  > Out of curiosity - which tree was this diff generated against? The
>  > line number here looks to be off by several hundred from what I
>  > see in the repo right now.
> 
> This is inteded to be applied with the other patches in the series, the ones
> beginning with "[PATCH v2] ld: Generate PDB string table" at
> https://sourceware.org/pipermail/binutils/2022-November/thread.html.
> 
> Sorry, this probably wasn't obvious from a mail client. I've not numbered
> them as I'm not sure how many more there'll be, and if I wait for the previous
> patches to be accepted before submitting the next, I'll almost certainly miss
> the cut-off for the code freeze.

Such dependencies, if not otherwise obvious (like in a properly threaded
and numbered series) need calling out in a post-commit-message remark.

>  > Why / when would in->outsymbols be NULL but in->symcount be non-zero?
> 
> Try running the test in the DEBUG_S_LINES patch without this one - it'll fail
> because ld segfaults. outsymbols doesn't get set from within generate_reloc
> for the second object file, as it only has one non-loadable section. The
> "symbols" come from the .equs I'm using like #defines.

And then why would such symbols not need emitting debug info for? What
you say above and ...

>  > And if that was possible, why would it not also be possible that the
>  > array is smaller than in->symcount?
> 
> bfd_generic_link_read_symbols is called for each loadable section, and
> allocates the outsymbols array once. It was my mistake when I submitted my
> original patch for populate_publics_stream, in not realizing that it would
> break for object files without any loadable sections.

... here makes me think that assuming it is the right thing to do, it
wants not only properly describing in the patch, but should actually be
accompanied by a code comment.

Jan