Re: [ld] build_link_order question

[Gunther Nikl <gnikl at justmail dot de>]

Alan Modra wrote:
> On Tue, Apr 10, 2018 at 06:14:39PM +0200, Gunther Nikl wrote:
> > Hello,
> > 
> > I am using an out-of-tree a.out target (m68k-amigaos). When placing
> > the (a.out?) COMMON section into a .data output section the link
> > fails in aoutx.h/get_reloc_upper_bound with
> > "bfd_error_invalid_operation". AFAICT, this is because ld creates a
> > link_order statement since the output section ".data" has contents.
> > That is contrary to the usual destination ".bss"  where
> > SEC_HAS_CONTENTS is not set. Is this a limitation of
> > ldwrite.c:build_link_order/lang_input_section_enum? For a test I
> > added a check there that catches input sections without contents to
> > not create a link order. Then the link succeeds. Is this a proper
> > solution?
> 
> No.  AOUT is a very limited format.

Is that relevant for the issue at hand?

> Your problem is that somehow you are creating sections that don't
> match one of obj_textsec(output_bfd), obj_datasec(output_bfd) or
> obj_bsssec(output_bfd).

Yes, aoutx.h/aout_link_check_ar_symbols creates a section named "COMMON"
since the input object contains a common symbol. If that COMMON section
is placed into a ".bss" output section everything is fine since this
section type does not have contents, thus no link order. If output
section with no contents don't get link order objects, why should
should input section having the same attribute create a link order?

I changed ldwrite.c:build_link_order because then the input object type
does not matter. If a change in bfd/aoutx.h is preferred then
get_reloc_upper_bound and canonicalize_reloc have to be changed and a
test for that COMMON section has to be added.

Regards,
Gunther Nikl