Dear port-sparc NetBSD mailing list:

Over the last few days, I've attempted to get lcc 3.5 working under NetBSD 1.1.
It looks like my /sbin executables are dated November 21, 1995, but I know
that I ftp'ed the installation and sources in late January.

I had to modify the lcc "machine description" file to produce ".common" and
".reserve" assembler directives that conform to GAS's formats, and to
remove the st2 and ld2 pseudo-op-codes.

On my trusty old SS-IPC, lcc 3.5 generates SPARC assembly code that
makes the NetBSD version of GAS put "bss" segment data on incorrectly
aligned boundaries.  


It appears that GAS (GNU assembler version 1.92.3, NetBSD $Revision: 1.3 $)
doesn't do the ".align" assembler directives correctly.  The SPARC code
generator that comes with the lcc 3.5 distribution generates assembly for bss
segment data that looks like this.

.seg "bss"
.align 1
.reserve _buf,4610,"bss"
.align 4
.reserve _bsize,4,"bss"

This is different than gcc-generated assembly for the same C source code:

    .reserve _bsize,8,"bss"

    .reserve _buf,4616,"bss"

GCC seems to be just putting every bss or data segment storage at a
divisible-by-8 address, and making sure that the allocations are multiples
of 8

Is this a "feature" of GCC and GAS working together, or is it a bug?  Doesn't
the practice of rounding everything up to a divisible-by-8 address waste
a fair amount of space in executable files?

I compiled lcc 3.5 with the NetBSD gcc compiler, then compiled the following
code with the gcc-compiled lcc:

--cut here--
static int bsize;
static char buf[4610];

void main(void);

void
main()
{
        printf("buf at 0x%08x, bsize at 0x%08x\n", buf, &bsize);
        bsize = -1;

        return;
}
--cut here--

Then I compile doing something like this:

% lcc -B./ -d0.1 -A -Wf-target=sparc-sun \
        -I../../src/../include/sparc/sun \
        -I../../src -S -o test2.s test2.c

% lcc -B./ -o test2 test2.s

I did the compilation in 2 steps so I could see the generated 

assembly language.  That was what I pasted in above.

% nm test2
00002020 F /usr/lib/crt0.o
00004000 d __DYNAMIC
000040b4 D ___progname
000052f2 b _bsize  <======= an int, on an divisible-by-2 boundary.
000040f0 b _buf
000027e8 T _dlclose
00002850 T _dlctl
000028a4 T _dlerror
000027b0 T _dlopen
00002818 T _dlsym
000040b8 D _edata
00005308 B _end
000052f8 B _environ
00005300 B _errno
00002c30 T _etext
00002938 T _main
00002020 T start
00002938 F test2.o

% ./test2
buf at 0x000040f0, bsize at 0x000052f2
zsh: 17509 bus error (core dumped)  ./test2

% gdb test2 test2.core
(no debugging symbols found)...
Core was generated by `test2'.
Program terminated with signal 10, Bus error.
Reading symbols from /usr/libexec/ld.so...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libm.so.0.1...(no debugging symbols found)...
done.
Reading symbols from /usr/lib/libc.so.12.3...(no debugging symbols found)...
done.
#0  0x2968 in main ()
(gdb) where
#0  0x2968 in main ()
(gdb) x/i 0x2968
0x2968 <main+48>:       st  %i4, [ %i5 ]
(gdb) p $i4
$1 = -1
(gdb) p $i5
$2 = 21234
(gdb) printf "0x%x\n", $i5
0x52f2  <===  address of bsize storage, divisible-by-2 address