🚀 go-pugleaf

An appeal for help:

I am trying to produce Sun-3-format a.out format files (with
relocation bits) for an *embedded* system with an on-the-fly
relocating loader (no kidding).

I am running on a Sun-4 (SunOS 4.1), using gld (1.94 beta and
gas-1.38, all configured for Sun-3 cross-development.

My test program fails to execute correctly, and as near as I can tell
the problem seems to be interaction of the loader (over which I have
no control), the relocation information of data/bss/common in my
binaries, and the behavior of our "crt0" startup.

I know this is probably an ignorant request, but getting this to work
*REAL SOON NOW* is a lot more important than my dignity.

\begin{awesome_display_of_ignorance}

In short, how can I keep gld from mapping 'C' (common) symbols to some
other section?  I've tried hacking *68k.sc files and get

"bfd error writing file tiny, format a.out-sunos-big can't represent section COMMON"

However, when I run "nm" on a binary I know was built using Sun3 SunOS
4.0.3 ld, and which works correctly, I get:

00000004 C _fd_stderr
00000004 C _fd_stdin
00000004 C _fd_stdout

which I take to be an existence proof to the contrary.  gld, however,
maps these common symbols from our "crt0" to the bss section.

000008e4 B _fd_stdout
000008e8 B _fd_stdin
000008ec B _fd_stderr

\end{awesome_display_of_ignorance}

I have neither a SunOS 4.0.3 Sun-3, nor relocating loader source (grrr...).

BTW, my test program is

.text
        .even
.globl _main
_main:
        clrl sp@-
        jbsr _exit
        rts

John Morrison (posting from Warren's account)
jm@mak.mak.com = jm@[192.124.140.1] (We're new to the net)
-- 
MaK Technologies, Inc.
380 Green Street
Cambridge, MA 02139
(617) 876-8085