[ld] build_link_order question

[Gunther Nikl]

Hans-Peter Nilsson <hp@bitrange.com> wrote:
> 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,

a.out target in the AmigaOS/m68k context has a different meaning.
It refers to gas creating a.out objects. The ld generated final
executable is in the AmigaOS native target format called HUNK.
The port uses a.out for object files because its an old port
predating BFD. You could use GAS (almost) as-is and you only had
to teach the linker the Amiga native file format.

> 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.

I never considered utilizing objcopy. And I have no idea if objcopy
would be able to create working executables.
I have considered switching GAS to ELF. However as surprising it might
sound, ELF for m68k lacks a feature that a.out offers: BASE<16,32>
relocations. Without such relocations a major feature of the toolchain
would be gone.

Regards,
Gunther Nikl