The problem with linkonce sections in ELF

H . J . Lu
Thu Feb 3 16:50:00 GMT 2000

On Thu, Feb 03, 2000 at 07:08:21PM -0500, Ian Lance Taylor wrote:
>    Date: Thu, 3 Feb 2000 13:55:37 -0800
>    From: "H . J . Lu" <>
>    > I think I found the problem. build_link_order () is called very
>    > late. Before that, the input section list of the output section
>    > is always empty. When we strip a linkonce section,
>    > _bfd_strip_section_from_output removes the corresponding output
>    > section by mistake since its input section list is empty. I don't
>    > know what the best fix is.
> I don't understand this explanation.  Why is it incorrect to remove an
> output section which has no input sections?  An output section with no
> input sections should not occupy any space in any case.

It is not there are no input sections. It is just that they haven't
been assigned to the output section yet. It is done in
build_link_order (), which is called very late from ldwrite ().

> _bfd_strip_section_from_output should only be called for sections
> created by the linker.  Are you saying that you have input sections
> with the same name as sections which the linker creates?  That could
> indeed be a problem, and I don't think your patch is the correct fix
> for that.

_bfd_strip_section_from_output () is called by
elf_i386_size_dynamic_sections () in elf32-i386.c on
".rel.gnu.linkonce.t*" sections. They are created by linker.
But for some reason. they are not put on the input section
list. I will look into it more.

>    Ian, how about this patch? It seems to work for me.
> First of all, I don't understand why this patch is needed or correct.
> This patch appears to do extra work.  I think it would be easier to
> build the link order in wild_doit.  I don't understand the ASSERT in
> setup_output_link_order; it seems to me that it will trigger for a
> linkonce section which is being discarded.

It was just cut and paste.

> I don't think it is appropriate to change bfd_new_link_order in this
> fashion.  That function is very simple, and I think it should remain
> simple.  Instead, if this is in fact the right way to go, we should
> change the linker to do something else.

H.J. Lu (

More information about the Binutils mailing list