🚀 go-pugleaf

GCC 1.35 produces plausible but wrong output for some kinds of input.
The problem is that the assembler 'space' pseudo-op is being used in
the text segment, but this does not work.

Sample input file (one line):

> const char foo[40] = {0};

Invoking command:

> gcc -v -S test.c

console output:

---
gcc version 1.35
 /usr/local/lib/gcc-cpp -v -undef -D__GNUC__ -Dmc68k -Dunix -Dunixpc -D__mc68k__ -D__unix__ -D__unixpc__ test.c /tmp/cca12488.cpp
GNU CPP version 1.35
 /usr/local/lib/gcc-cc1 /tmp/cca12488.cpp -quiet -dumpbase test.c -version -o test.s
GNU C version 1.35 (68k, SGS/AT&T unixpc syntax) compiled by GNU C version 1.35.
---

Assembler file (6 lines):


	file	"test.c"
	global foo
text
foo:
	byte 0
	space 39

This is plausible but does not work right.  I haven't tracked down the
details, but the 'space' operation definitely does not work right in the
'text' context.  It may be allocating space in the data segment, but I
suspect that what's happening is that the space it allocates is not
zeroed if it's in the text segment.  What I got was two bytes of zeroes,
and a bunch of bytes of something else (all the same: not too interesting.)
You may call this a bug in the assembler, or in the loader, or whatever,
but we're not likely to get new ones unless FSF provides them, so we're
stuck...

This emerged because of a particular usage in Nethack, which used a
buffer of zeros to be written (under various casts, and with various
lengths) to a save file.  Using the -traditional switch makes Nethack
#define const to nothing, so the whole thing appears in the data segment
and the problem disappears, because foo is defined in the data segment.