Return to BSD News archive
Newsgroups: comp.os.386bsd.questions
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: cross-compiling (linking actually) using gnu tools
Message-ID: <1993Mar10.220555.3012@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1993Mar8.030202.26276@craycos.com>
Date: Wed, 10 Mar 93 22:05:55 GMT
Lines: 89
In article <1993Mar8.030202.26276@craycos.com> scott@craycos.com (Scott Bolte) writes:
>
> I could use some help setting up a cross compilation
> environment from a Sparc system to 386BSD using the GNU tools.
> I have everything working except for ld. Ideally I would like
> to get this going before ref.tfs.com goes away so I can verify
> that it all works.
>
> The parts that have been verified to work:
>
> gcc-2.3.3
> gas-1.38
> binutils-2.1
> ranlib
> ar
>
> And the only missing component is ld. It will link a binary
> without error messages. But when an attempt is made to run it
> on ref.tfs.com it complains: "./a.out: Cannot allocate memory."
I've been running a cross-compilation environment since before 0.1 was
released, mostly becaus I couldn't get 0.0 to boot without getting it to
boot... I had the AT&T/HP Vectra problem (patch 2 in the first patchkit).
I used the sources for the compiler, linker, etc. on the distribution
disks for 386BSD rather than pulling down copies from GNU.
> I have used objdump (from binutils 2.1) to see how a program
> linked on a sun (using the gnu loader) and one linked under
> 386bsd (using the system loader) differ. The results are
> included below.
>
>sun% objdump -f 386-main
>386-main: file format a.out-i386-bsd
>architecture: i386, flags 0x000001be:
>EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, WP_TEXT, D_PAGED
>start address 0x00000000
>
>sun% objdump -f gnu-main
>gnu-main: file format a.out-i386-bsd
>architecture: i386, flags 0x000001be:
>EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, WP_TEXT, D_PAGED
>start address 0x00000004
I think the problem is which sys/exec.h you are using. The a.out.h
includes sys/exec.h; on the Sun, the struct exec has an initial lead-in
character for __DYNAMIC flagging and a toolversion for which major version
of the tools you used (to match ld with ld.so).
Basically, I had to take care that the right exec.h got included.
I think the 0x00000004 (as opposed to 0x00000001) is a result of strict
alignment requirements on writing out the file.
I can't remember if I had to byte-swap output to the file to make it work,
but I remember something along those lines.
> The loader has two emulation modes for a 386: i386aout and
> i386coff. But the Binary File Descriptor code, in the bfd
> subdirectory, seems to have additional modes for bsd and
> linux. Now the "file format" tag, a.out-i386-bsd, from the
> headers above seems to indicate that I am using the i386bsd.c
> code from the bfd library. (This is using i386aout emulation
> mode of ld.) But even though it all looks ok to me, a gnu
> gcc/ld/etc newbie, it still does not work.
Another thing you might want to do is pull a working binary across from
a program compiled with gcc2.3.3 on a real 386BSD system (ie: ref.tfs.com)
that doesn't include much to make it a smaller compare, and then compare
them with od/hd. I'd suggest:
main()
{
write( 1, "Hello world\n", 12);
}
This was my test case.
Terry Lambert
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------