Re: [ld] build_link_order question

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Tue, 10 Apr 2018, 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?

It's not the a.out->a.out solution you ask for, but as using
a.out is bound to run into (increasingly) marginal issues I'd
suggest something else: change the port to compile and link
using ELF, then as a *post-link* step convert to a.out, defining
POST_LINK_SPEC in gcc for m68k-amigaos to do an objcopy
format-change copying construct, provided that you can make that
work without too much effort.

(I think I'll move to this scheme for mmix-mmixware since
linking from ELF to mmo is causing e.g. LTO problems that I
don't really have an incentive to fix, being a rare
"cross-format" target.  The corresponding objcopy construct
works here.  It should be possible to make cross-format-link
work even for LTO, but I don't really see why to bother.  And
no, it's not the same thing, just similarly marginal.)

If you have already considered and rejected this, it'd be
interesting to hear some reasons.

brgds, H-P