ld's --orphan-handling vs empty linker-generated sections

ld's --orphan-handling vs empty linker-generated sections

[Jan Beulich]

Hello,

we've been considering to make use of this command line option to
trigger warnings during the building of Xen. I'm puzzled though by
the warning being issued for certain linker generated (as per the
sections' flags) sections.

For one there's .got, .plt, and alike. When building OS-kernel-like
binaries, these are often expected (or even required) to be empty.
Hence I would have thought there shouldn't be a need to name these
in the linker scripts, but I don't see how else I could silence the
resulting warnings.

The other yet more puzzling set are various .rela.* sections. I
can't even derive on what basis these are made. For example I see
one for .text and .data.rel.local, but none for .data. No
relocations are to remain anyway (we're not asking for them to be
retained), so their origin is quite unclear to me. I do note though
that the various scripts under ld/scripttempl/ indeed mention them.
I have to admit that I wasn't aware these need mentioning; I was
rather expecting they would be like e.g. .symtab and .strtab, which
also aren't explicitly named.

My first thought was to simply suppress the warning for empty linker
generated sections in ldlang_place_orphan(). But it looks like final
section sizes aren't known yet at that point, so "emptiness" cannot
be determined at this point. Most sections are still empty at that
time (but may not be in the end), while at least for x86-64 .got.plt
isn't empty at this point, yet doesn't appear in the final binary.

I would appreciate any insight here as well as hints towards the
"canonical" silencing of this diagnostic. Having to enumerate all
sections the linker might instantiate (and then drop again from the
output for being empty) doesn't really work well, after all. As soon
as new ones appear, one would need to fiddle with linker scripts
again.

Thanks, Jan

Re: ld's --orphan-handling vs empty linker-generated sections

[Andrew Burgess]

Jan Beulich via Binutils <binutils@sourceware.org> writes:

> Hello,
>
> we've been considering to make use of this command line option to
> trigger warnings during the building of Xen. I'm puzzled though by
> the warning being issued for certain linker generated (as per the
> sections' flags) sections.
>
> For one there's .got, .plt, and alike. When building OS-kernel-like
> binaries, these are often expected (or even required) to be empty.
> Hence I would have thought there shouldn't be a need to name these
> in the linker scripts, but I don't see how else I could silence the
> resulting warnings.
>
> The other yet more puzzling set are various .rela.* sections. I
> can't even derive on what basis these are made. For example I see
> one for .text and .data.rel.local, but none for .data. No
> relocations are to remain anyway (we're not asking for them to be
> retained), so their origin is quite unclear to me. I do note though
> that the various scripts under ld/scripttempl/ indeed mention them.
> I have to admit that I wasn't aware these need mentioning; I was
> rather expecting they would be like e.g. .symtab and .strtab, which
> also aren't explicitly named.
>
> My first thought was to simply suppress the warning for empty linker
> generated sections in ldlang_place_orphan(). But it looks like final
> section sizes aren't known yet at that point, so "emptiness" cannot
> be determined at this point. Most sections are still empty at that
> time (but may not be in the end), while at least for x86-64 .got.plt
> isn't empty at this point, yet doesn't appear in the final binary.
>
> I would appreciate any insight here as well as hints towards the
> "canonical" silencing of this diagnostic. Having to enumerate all
> sections the linker might instantiate (and then drop again from the
> output for being empty) doesn't really work well, after all. As soon
> as new ones appear, one would need to fiddle with linker scripts
> again.

Just for context, when I originally proposed this flag, I was working on
smaller embedded targets for which .plt, .got, etc were not an issue.
As a result, I never really considered how these might be handled.

It's possible something has been added between then and now, but, it
might also be the case that there is no "canonical" solution for what
you want, you may have to invent one!

Good luck,
Andrew