ld doesn't respect chip/fast sections on object files

[mankeli]

When compiling one source with vasm that has data/data_c sections, and then linking that .o file into c-program compiled with gcc, the output file sections don't have the memory bits set anymore.

Repro:

src1.s

test
  data_c
  db "hello"

  data
  db "world"

src2.c

#include <stdio.h>

int main()
{
  return 0;
}

compile with:

vasmm68k_mot -Fhunk src1.s -o src1.o
m68k-amigaos-gcc src2.c src1.o -o out.exe

Not sure which public tool can be used to inspect the result easily, but the chip/fast bits of the src1.o don't exist anymore in the resulting out.exe.

[bebbo]

that's a linker issue... you have to use the correct section names, as used in gcc.

[bebbo]

Not sure which public tool can be used to inspect the result easily, but the chip/fast bits of the src1.o don't exist anymore in the resulting out.exe.

you may try hunkdump or one of the other hunk dumping tools...

 hunkdump test
reading ../tickets/agc333/test
hunk 000003f3,      HUNK_HEADER,          0
5 sections, 0 - 4 
sizes: 8000, 296, 116, 8(c), 2097152(c)
hunk 000003e9,        HUNK_CODE,       8000
hunk 000003ec,     HUNK_RELOC32,        220
hunk 000003f0,      HUNK_SYMBOL,          8
HUNK_END
hunk 000003ea,        HUNK_DATA,        296
hunk 000003ec,     HUNK_RELOC32,         20
hunk 000003f0,      HUNK_SYMBOL,         12
HUNK_END
hunk 000003eb,         HUNK_BSS,        116
hunk 000003f0,      HUNK_SYMBOL,         16
HUNK_END
hunk 000003ea,        HUNK_DATA,          8
hunk 000003f0,      HUNK_SYMBOL,          8
HUNK_END
hunk 000003eb,         HUNK_BSS,    2097152
hunk 000003f0,      HUNK_SYMBOL,          8
HUNK_END

[mankeli]

Ah I see. Yes, using ".datachip" as the section name did the trick. And I tried hunkdump earlier but didn't realize it showed the memory flags. Thank you and sorry for the noise. :)