Chip DATA section lost with -Os and chip BSS present

[jcornwall]

chipbug.zip

In this test case there is initialized and zeroed chip data. With -Os the initialized data does not appear in the executable. Attempting to read from it in the program gives zeros. I guess the symbol references the BSS section instead.

Either removing the __chip qualifier, removing -Os, or removing the chip BSS section resolves the problem.

[bebbo]

I loaded chipbug_bad into a debugger and both symbols are present in chip memory.

What happens is: The linker merges the chip_bss section into the data_bss section, which IMHO is legal.

Disassembly of section .data:

00000000 <_test_data>:
   0:   1234 5678

00000004 <_test_bss>:
   4:   0000 0000

[jcornwall]

Hmm. I see both symbols merged into BSS, rather than data, with chipbug_bad.

hunktool -A info chipbug_bad  
chipbug_bad (0.0001s) TYPE_LOADSEG
          header (segments: first=0, last=1, table size=2)
    #000  CODE   size 00000004  alloc size 00000004  file header @0000001c  data @00000024  
          symbol  #4
            00000004  __etext                           
            00000004  ___datadata_relocs                
            00000000  __stext                           
            00000000  _main                             

                _main:
00000000    7000                          moveq   #0,d0            
00000002    4e75                          rts                      

    #001  BSS    size 00000008  alloc size 00000008  file header @00000080  
          symbol  #2
            00000000  _test_bss                         
            00000004  _test_data   

(Objdump doesn't show the BSS segment so I used hunktool here instead.)

[bebbo]

my output is from m68k-amigaos-objdump -S chipbug_bad

my own tool reports:

> hunkdump.exe chipbug_bad
reading chipbug_bad
hunk 000003f3,      HUNK_HEADER,          0
4 sections, 0 - 3
sizes: 5864, 328, 96, 8(c)
hunk 000003e9,        HUNK_CODE,       5864
hunk 000003ec,     HUNK_RELOC32,        344
hunk 000003f0,      HUNK_SYMBOL,         12
HUNK_END
hunk 000003ea,        HUNK_DATA,        328
hunk 000003ec,     HUNK_RELOC32,         40
hunk 000003f0,      HUNK_SYMBOL,         16
HUNK_END
hunk 000003eb,         HUNK_BSS,         96
hunk 000003f0,      HUNK_SYMBOL,         12
HUNK_END
hunk 000003ea,        HUNK_DATA,          8
hunk 000003f0,      HUNK_SYMBOL,         12
HUNK_END

So the chip data has a size of 8 bytes has the chip memory attribute.

To verify I loaded it into an Amiga debugger and both chip memory addresses are really in the chip memory.

EDIT: version info: GNU ld version 2.14b 20180609-214714 gcc version 6.4.1b 20180616-173350 (GCC)

[bebbo]

btw you can use objdump to display the sections too:

>  m68k-amigaos-objdump.exe -h chipbug_bad

chipbug_bad:     file format amiga

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000016e8  00000000  00000000  0000002c  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE
  1 .data         00000148  00000000  00000000  00002084  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  2 .bss          00000060  00000000  00000000  000022c8  2**2
                  ALLOC
  3 .data         00000008  00000000  00000000  000023d4  2**2
                  CONTENTS, ALLOC, LOAD, DATA

[jcornwall]

Looks like my amiga-gcc update attempt failed. It seems I still have a May 4th build (not too old but maybe something changed?) and it generates this:

chipbug_bad:     file format amiga

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000004  00000000  00000000  00000024  2**2
                  CONTENTS, ALLOC, LOAD, CODE
  1 .bss          00000008  00000000  00000000  00000088  2**2
                  ALLOC```

I tried doing a 'make clean' and 'make' but end up with:

m68k-amigaos-gcc -Os -DCHIP_BSS -o chipbug_bad chipbug.c
/home/jay/env/m68k-amigaos/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: cannot open crt0.o: No such file or directory

[bebbo]

git pull
make update -j
make all

should do it - if the result is not ok go the long way:

git pull
make clean clean-prefix update -j
make all

[jcornwall]

Yep, that worked! It seems that bug was indeed fixed in the last month.

I think using -j broke my update, because I tried it again after a clean and it finished very quickly. I then cleaned again and started without -j and it spent a lot longer rebuilding everything. I'll be sure to clean and build single threaded in future.

Thanks for the help.