Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!csource!david
From: david@csource.oz.au (david nugent)
Newsgroups: comp.unix.i386
Subject: Re: gas on ISC 386/ix
Keywords: gas,386/ix
Message-ID: <554@csource.oz.au>
Date: 5 Jul 90 14:51:39 GMT
References: <551@csource.oz.au> <1279@tuewsd.win.tue.nl>
Organization: Unique Computing Pty Ltd, Melb, Aust.
Lines: 85

In comp.unix.i386 you write:

>>Has anyone managed to get GNU's assembler running under Interactive
>>386/ix yet?  I got it to compile with few problems, but now I'm faced
>>with what appears to be an 'incompatible' a.out format that it seems
>>to be producing.  The object files it produces are rejected by the 
>>linker.

>Yep, you need to use the GNU loader, and all other binutils, as the
>object format is indeed different. (you need a different ar, nm, strip,...)

>There also is a util to convert the normal libraries to GNU format,
>so as to be able to link gcc-gas generated code with standard libs.

Ahh, thanks!

I'm only just starting out on the (apparently long) road to getting
most of the gnu stuff going here.  Fortunately, I have most of it,
but hadn't got anywhere near binutils yet. :-)

This is excellent news; I had almost left the project alone for some
time because of this stumbling block.  gcc works fine (in fact
_brilliantly_).


>Going with gas is a serious commitment.

Good.  I'm prepared for it.  I have to port a complete C library, and
I needed a tool that I can take to as many other machines without
having to worry too much about the tools themselves.


>But it can become necessary when you start hitting bugs or limitations
>in the AT&T assembler or linker (as you do with g++)

I've already hit 'em.  :-(  And that's just with gcc - it produces some
code occasionally which /bin/as just can't handle.  Looking at the .s
produced, I can't see why it's complaining at all sometimes.  The sources
for the Unix lharc, for example - lzhuf.c -> lzhuf.s just won't assemble
after being compiled via gcc.

BTW, have you come across the problem with passing non-const literal
strings to some library functions?  Causes "bus error" and memory
faults.  It seems that literals used as arguments or as initialisers
to statically declared pointers are placed in a "read only" segment data
area (perhaps this is an ANSI C requirement?).  I'm finding I have to 
change a bunch of code as a result, first copying the literal into a 
local buffer, then passing the buffer address to the function.

To demonstrate, one function which particularly hurts is mktemp(), since
it changes it's argument (at least in ISC's library):

I have to change:

	fptr = mktemp ("/tmp/xyzXXXXXX");

to:

	char localbuf[PATHLEN];

	strcpy (localbuf, "/tmp/xyzXXXXXX");
	fptr = mktemp (localbuf);

Alternatively;

	static char localbuf[[PATHLEN] = "/tmp/xyzXXXXXX";

	fptr = mktemp (localbuf);

I tend to favour the second method, since it reinitialises the
variable on each call to the function.

Hmm, I just thought of another workaround: replace mktemp() and
strdup() the new string (requiring no changed in code).  Only problem
is that it never gets free()'d which could cause unnecessary memory 
fragmentation.

Thanks again for the help,

david


-- 
_______________________________________________________________________________
 Unique Computing Pty Ltd  Melbourne  Australia  -  Communications Specialists 
        david@csource.oz.au    3:632/348@fidonet    28:4100/1@signet