Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!rex!wuarchive!julius.cs.uiuc.edu!apple!uokmax!rmtodd
From: rmtodd@uokmax.ecn.uoknor.edu (Richard Michael Todd)
Newsgroups: comp.unix.aux
Subject: Re: GCC/GAS problem
Keywords: gcc, gas, ambiguity
Message-ID: <1990Oct5.034323.14458@uokmax.ecn.uoknor.edu>
Date: 5 Oct 90 03:43:23 GMT
References: <2908@sequent.cs.qmw.ac.uk>
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK
Lines: 35

liam@cs.qmw.ac.uk (William Roberts) writes:
>Motorola mnemonics and the variant which the m68k.c file in gas understands.
>Most other UNIX C compilers get round this by a convention which puts an
>underscore on the beginning of all C variable names and labels, so that the
>ambiguity is removed. This in turn leads to strange perversions in the
>linker which has to believe that "lable" matches "_lable".

[A good many non-Unix C compilers do this too, either putting a _ in front
of or at the end of symbols declared in C code.  I recall Aztec C doing
this on a PC, and I had to do something similar when I got Small-C running
on my Model I, when I noticed that declaring an "char *sp;" did interesting
things :-).  I suspect almost every C compiler that produces assembly code
does this.  Don't recall *ever* seeing a linker that mapped "_label" to
"label" or vice versa, though; most of the ones I've seen assumed that
anyone writing assembly routines to be called from C would know where this
C compiler put the "_" in label names.]

>Consider the following bit of code (you can guess what's coming...)

[code segment that uses lots of variables with the same name as registers
deleted]

>If it doesn't, then I think the following needs to be done:

>1) Modify gcc again so that there is a prefix character on labels
>2) Modify gas to use the prefix character to disambiguate labels/registers

John Coolidge has already done this, on the version of gcc/gas available for
ftp from wuarchive.wustl.edu.  (I believe the charhe's using on aregister names
is '%').  I guess this newest version hasn't made it across the Atlantic
yet.  Anyway, your program compiles with no problems on the current version 
(except that the linker objects that you never provided a function "foo" :-).

-- 
Richard Todd   rmtodd@chinet.chi.il.us  or  rmtodd@uokmax.ecn.uoknor.edu