Linker issues with larger projects

[mheyer32]

adoom_gcc.zip

Attached you'll find the whole ADoom project that I'm trying to compile for a while now. I've come as far as to the linking stage, but there's always some issues with relocations that I cannot seem to find a way around. No amount of permutations of -mcrt=clib2, -noixemul, -fbaserel, -fbaserel32 (or the lack of -fbaserel) got me anywhere - there's always some object files the linker complains about, be it objects from the project itself or objects from the c runtime libs.

Since I'm dependent on libnet, I'm stuck with -mcrt=clib2. -fbaserel32 is not a good solution. Its slow, not supported by vasm and not a good solution in general (32bit offsets to a 32bit base - we could use absolutes in that case and be faster)

Thanks for your help!

[bebbo]

The .data and .bss segments are to large for using baserel.

But why was it working with SAS/C?

The solution is found e.g. in tables.c: FAR int finetangent[4096] = ...

The FAR keyword places the the data in a different data segment. The current gcc linker uses the aout format which has no support for more than the 3 sections: .text, .data, .bss.

Similar to the CHIP keyword FAR requires a separate section. Then the normal data section becomes small enough to fit into one 64k block.

To implement this, full amiga_hunk support is mandatory.

[bebbo]

Workaround for now:

You could replace all FAR/CHIP variables with pointers and initialize those via allocated memory. If initialization data is required, read that data from a file into the allocated ram.

FAR int finetangent[4096] = ...

becomes

int * finetangent;

void __init_finetangent() {
  finetangent = (int *)AllocVec(4096*sizeof(int), MEMF_ANY);
  FILE * f = fopen("finetangent.dat", "rb");
  fread(finetangent, 4096, sizeof(int), f);
  fclose(f);
}
void __exit_finetangent() {
  if (finetangent) FreeVec(finetangent);
}
ADD2INIT(__init_finetangent,111);
ADD2EXIT(__exit_finetangent,111);

[mheyer32]

Thanks, bebbo!

Ok, so currently fbaserel is out the window. But why do absolute and fbaserel32 also fail?

[bebbo]

The provided assembler files are using the baserel 16 bit mode. Thus linking with any other variant will fail.

You'd need to modify the assembler files.

[mheyer32]

On Mon, Dec 11, 2017 at 12:13 AM bebbo notifications@github.com wrote:

The provided assembler files are using the baserel 16 bit mode. Thus linking with any other variant will fail.

You'd need to modify the assembler files.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bebbo/gcc/issues/5#issuecomment-350650978, or mute the thread https://github.com/notifications/unsubscribe-auth/Af_HD7LbTNTF-G9VRJfhOWMTplv3n0Bmks5s_OQVgaJpZM4Qzj6m .

Yes, Im aware of that. I think I could change the assembly files to use absolute addresses instead.

I’ll try that and also hope for Amiga hunk support in future :)

[mheyer32]

taking away the small-code optimizations and removing the -fbaserel options, I can't link the project either. Do you have a suggestion on how to get around that?

`m68k-amigaos-gcc -v -mcrt=clib2 -Ofast -m68030 -m68881 -fomit-frame-pointer -Wimplicit -Wno-strict-prototypes -Wno-int-conversion -DVERBOSE -D__BIG_ENDIAN__ -DNORMALUNIX -Diabs=abs  doomdef.o doomstat.o dstrings.o amiga_sound.o amiga_system.o amiga_net.o amiga_plane.o amiga_segs.o amiga_data.o amiga_wad.o amiga_sight.o amiga_things.o amiga_median.o amiga_video.o amiga_draw.o amiga_sega.o amiga_music.o c2p_8_020.o c2p_6_020.o c2p_8_030.o c2p_8_040.o c2p_6_040.o c2p8_040_amlaukka.o amiga_mmu.o m_argv.o dehacked.o tables.o f_finale.o f_wipe.o d_main.o d_net.o d_items.o g_game.o m_menu.o m_misc.o m_bbox.o amiga_fixed.o m_swap.o m_cheat.o m_random.o am_map.o p_ceilng.o p_doors.o p_enemy.o p_floor.o p_inter.o p_lights.o p_map.o p_maputl.o p_plats.o p_pspr.o p_setup.o p_sight.o p_spec.o p_switch.o p_mobj.o p_telept.o p_tick.o p_saveg.o p_user.o r_bsp.o r_data.o r_draw.o r_main.o r_segs.o r_sky.o r_things.o w_wad.o wi_stuff.o v_video.o st_lib.o hu_stuff.o hu_lib.o s_sound.o z_zone.o info.o sounds.o r_plane.o st_stuff.o amiga_main.o \
-lnet -o ADoom
Using built-in specs.
COLLECT_GCC=m68k-amigaos-gcc
COLLECT_LTO_WRAPPER=/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/libexec/gcc/m68k-amigaos/6.3.1b/lto-wrapper
Target: m68k-amigaos
Configured with: /home/matze/amigatoolchain/gcc-6.2/amigaos-cross-toolchain/submodules/gcc-6/configure --prefix=/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos --infodir=/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/info --mandir=/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/share/man --prefix=/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos --prefix=/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos --target=m68k-amigaos --enable-languages=c,c++,objc --enable-version-specific-runtime-libs --disable-libssp --with-headers=/home/matze/amigatoolchain/gcc-6.2/amigaos-cross-toolchain/.build-m68k/sources/ixemul-48.2/include
Thread model: single
gcc version 6.3.1b 20171201-203349 (GCC) 
COMPILER_PATH=/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/libexec/gcc/m68k-amigaos/6.3.1b/:/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/libexec/gcc/m68k-amigaos/6.3.1b/:/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/libexec/gcc/m68k-amigaos/:/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/:/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/lib/gcc/m68k-amigaos/:/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/../../../../m68k-amigaos/bin/
LIBRARY_PATH=/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/:/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/../../../../m68k-amigaos/lib/
COLLECT_GCC_OPTIONS='-v' '-mcrt=clib2' '-Ofast' '-mcpu=68030' '-m68881' '-fomit-frame-pointer' '-Wimplicit' '-Wno-strict-prototypes' '-Wno-int-conversion' '-D' 'VERBOSE' '-D' '__BIG_ENDIAN__' '-D' 'NORMALUNIX' '-D' 'iabs=abs' '-o' 'ADoom'
 /home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/libexec/gcc/m68k-amigaos/6.3.1b/collect2 -L/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib -fl libm020 -fl libm881 -o ADoom /home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/ncrt0.o -L/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b -L/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/../../../../m68k-amigaos/lib doomdef.o doomstat.o dstrings.o amiga_sound.o amiga_system.o amiga_net.o amiga_plane.o amiga_segs.o amiga_data.o amiga_wad.o amiga_sight.o amiga_things.o amiga_median.o amiga_video.o amiga_draw.o amiga_sega.o amiga_music.o c2p_8_020.o c2p_6_020.o c2p_8_030.o c2p_8_040.o c2p_6_040.o c2p8_040_amlaukka.o amiga_mmu.o m_argv.o dehacked.o tables.o f_finale.o f_wipe.o d_main.o d_net.o d_items.o g_game.o m_menu.o m_misc.o m_bbox.o amiga_fixed.o m_swap.o m_cheat.o m_random.o am_map.o p_ceilng.o p_doors.o p_enemy.o p_floor.o p_inter.o p_lights.o p_map.o p_maputl.o p_plats.o p_pspr.o p_setup.o p_sight.o p_spec.o p_switch.o p_mobj.o p_telept.o p_tick.o p_saveg.o p_user.o r_bsp.o r_data.o r_draw.o r_main.o r_segs.o r_sky.o r_things.o w_wad.o wi_stuff.o v_video.o st_lib.o hu_stuff.o hu_lib.o s_sound.o z_zone.o info.o sounds.o r_plane.o st_stuff.o amiga_main.o -lnet -lc -lamiga -ldebug -lgcc -lc
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/../../../../m68k-amigaos/bin/ld: Base symbol for base relative reloc not defined: section .text, reloc to symbol _spanstart
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/../../../../m68k-amigaos/bin/ld: BFD 2.14b 20170314 (adtools build 20080628) internal error, aborting at /home/matze/amigatoolchain/gcc-6.2/amigaos-cross-toolchain/submodules/binutils-2.14/bfd/amigaoslink.c line 249 in get_relocated_section_contents

/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/lib/gcc/m68k-amigaos/6.3.1b/../../../../m68k-amigaos/bin/ld: Please report this bug.

collect2: error: ld returned 1 exit status
Makefile:101: recipe for target 'ADoom' failed
make: *** [ADoom] Error 1
matze@ubuntu-VirtualBox:~/adoom_src$ 
`

[bebbo]

`Base symbol for base relative reloc not defined: section .text, reloc to symbol _spanstart

There are still baserel references left

[mheyer32]

I looked into this and indeed, it is VASM producing relative relocations. At first I thought it should be enough to remove all 'near a4,2' statements from the assembly files, but that's not enough. In the code itself there are references to external symbols like

move.l _spanstart(a4), d0

that will cause VASM to emit relative relocations.

I don't really want to change all assembly files and rather wait for full hunk support.

As part of the Amiga hunk support, will gcc also get the 'far' qualifier? The ADoom source (for SAS/C) seems to use it to group globals into two groups a) near symbols, addressed using base-relative and b) far symbols to pack large arrays and keep the near section smaller than 64kb

[bebbo]

I was able to link ADoom with the recent tool chain. Alas the clib2 does not provide auto initialization for the Amiga libraries, thus it crashes at the first use of the icon.library.

[mheyer32]

How did you manage to do that, what compiler options did you use? I just rebuilt the whole toolchain and get a ton of linker complaints.

My current options are: CFLAGS = -mcrt=clib2 -Ofast -fbaserel -m68030 -m68881 -fomit-frame-pointer -Wimplicit -Wno-strict-prototypes -Wno-int-conversion

dehacked.o(.text+0x370): relocation truncated to fit: DREL16 .bss
dehacked.o(.text+0x378): relocation truncated to fit: DREL16 .bss
dehacked.o(.text+0x3a0): relocation truncated to fit: DREL16 .bss
dehacked.o(.text+0x3a8): relocation truncated to fit: DREL16 .bss
dehacked.o(.text+0x4d0): relocation truncated to fit: DREL16 actions
dehacked.o(.text+0xbfe): relocation truncated to fit: DREL16 actions
dehacked.o(.text+0xb52): relocation truncated to fit: DREL16 oldsprnames
dehacked.o(.text+0xc16): relocation truncated to fit: DREL16 oldsprnames
dehacked.o(.text+0xcd2): relocation truncated to fit: DREL16 __iob
f_finale.o(.text+0xad4): relocation truncated to fit: DREL16 .bss
f_finale.o(.text+0xb14): relocation truncated to fit: DREL16 .bss
f_finale.o(.text+0x5a): relocation truncated to fit: DREL16 gameaction
f_finale.o(.text+0x6fe): relocation truncated to fit: DREL16 gameaction
f_finale.o(.text+0x64): relocation truncated to fit: DREL16 viewactive
f_finale.o(.text+0x68): relocation truncated to fit: DREL16 automapactive
f_finale.o(.text+0xa2): relocation truncated to fit: DREL16 finalestage

whats worse, though, I'm getting these also for runtime libs:

/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libnet.a(socket_obtain_daemon.o)(.text+0xe0): relocation truncated to fit: DREL16 __SocketBase
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libnet.a(socket_obtain_daemon.o)(.text+0x132): relocation truncated to fit: DREL16 __SocketBase
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libnet.a(socket_obtain_daemon.o)(.text+0x11a): relocation truncated to fit: DREL16 __no_standard_io
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libnet.a(socket_obtain_daemon.o)(.text+0x128): relocation truncated to fit: DREL16 __fd
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libnet.a(socket_obtain_daemon.o)(.text+0x1d0): relocation truncated to fit: DREL16 __is_daemon
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libc.a(stdlib_main.o)(.text+0xa2): relocation truncated to fit: DREL16 .bss
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libc.a(stdlib_main.o)(.text+0x4): relocation truncated to fit: DREL16 __UtilityBase
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libc.a(stdlib_main.o)(.text+0x16): relocation truncated to fit: DREL16 __UtilityBase
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libc.a(stdlib_main.o)(.text+0x1f6): relocation truncated to fit: DREL16 __UtilityBase
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libc.a(stdlib_main.o)(.text+0x1a): relocation truncated to fit: DREL16 DOSBase
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libc.a(stdlib_main.o)(.text+0x2c): relocation truncated to fit: DREL16 DOSBase
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libc.a(stdlib_main.o)(.text+0x3c): relocation truncated to fit: DREL16 DOSBase
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libc.a(stdlib_main.o)(.text+0x50): relocation truncated to fit: DREL16 DOSBase
/home/matze/amigatoolchain/gcc-6.2/m68k-amigaos/m68k-amigaos/clib2/lib/libb/libm020/libc.a(stdlib_main.o)(.text+0x92): relocation truncated to fit: DREL16 DOSBase

[bebbo]

Makefile: PFLAGS = -Fhunk -nosym -phxass -ldots -m68030 -m68882

amiga_macros.h: #define FAR __far

doomdef.h: remove empty FAR definition and add #include "amiga_macros.h"

amiga_video.c: must be same as in header - remove FAR

int SCREENHEIGHT;

amiga_main.c: add missing functions.

char *strupr(char *s)
{ unsigned char *s1;

  s1=(unsigned char *)s;
  while(*s1) {
    if (islower(*s1))
      *s1-='a'-'A';
    ++s1;
  }
  return s;
}

int strcmpi(const char *p1,const char *p2)
{ 
  for(;;) {
      char c = *p1++;
      if (c) {
      char d = *p2++;
      if (c >= 'A' && c <= 'Z')
          c |= 0x20;
      if (d >= 'A' && d <= 'Z')
          d |= 0x20;
        if (c == d)
          continue;

      } else
        ++p2;

      unsigned char a = *--p1;
      unsigned char b = *--p2;
      return (short)a - b;
    }
}

[mheyer32]

Ahh! -Fhunk was the offender.

I still had it on -Faout

I begin to understand how/why I got the "relocation truncated to fit:" messages. It has nothing to do with the file that the errors complain about. Is it because the 16bit section starts run out of space, so the symbols from the current file don't fit anymore.

Btw, strupr() and strcmpi() are defined in w_wad.c

[mheyer32]

Success! I also got it compiled and linked now. But only with -Os (which occasionally seems to crash gcc)

With -Ofast I always seem to run out of 'relocation space' - what are good mitigation strategies for these kinds of problems?