🚀 go-pugleaf

Well, I got past the first problem that I posted about a few days
ago (TIOCGETC is broken in readlin/ library for gdb 3.5 on SCO
Unix 386 v3.2) by munging together termio.h and sgtty.h.

Now I am stuck on this: the readline/ library builds fine, all
of the code in the dist-gdb/ top directory builds, but at
load time for 'gdb',{the function "asm" is undefined. I've
grep'd through all of the sources and read the output and
can not find any place where it is defined. Further, 'asm'
isn't defined in any system .h files, or anywhere else
I could think of to look. Even more frustrating, the exact same
sources on a vax compile without a glitch.

Can anyone please tell me where to find the definition for 'asm'
so that I can figure out what SCO did wrong this time? I really
need this debugger...

Thanks in advance yet again!~r
-- 
Jay Libove			Internet: libove@cs.cmu.edu
403 Village Green Blvd, Apt 203	BITNET: libove@drycas
Ann Arbor, MI 48105
(313) 747-7454

In article <8532@pt.cs.cmu.edu> libove@ius3.ius.cs.cmu.edu (Jay Libove) writes:
>at load time for 'gdb',{the function "asm" is undefined.

asm() isn't a function, it's a compiler directive to stick in some in-line
assembler.  The standard AT&T PCC compiler and GCC understand it perfectly
well, but the MS compiler that SCO gives out doesn't.  You lose.

You can probably build gcc and build gdb with that.  I know someone who did
roughly that, though the gcc build happened on 386/ix.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."

asm() is not really a function; it instructs the C compiler to place
literal text in the intermediate file which is fed to the assembler. It
is a way to place assembly language within C source files.

If your build is complaining about asm() being undefined, then I would
assuyme that you C compiler doesn't support asm() so it treats it as an
external function. Perhaps there is some compiler switch to allow asm.

Kevin

In article <1990Mar21.205356.5766@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
>In article <8532@pt.cs.cmu.edu> libove@ius3.ius.cs.cmu.edu (Jay Libove) writes:
>>at load time for 'gdb',{the function "asm" is undefined.
>You can probably build gcc and build gdb with that.  I know someone who did
>roughly that, though the gcc build happened on 386/ix.

I've built gdb with the MSC compiler (under SCO UNIX, of course 8-)), and
don't really remember this.  Well, I take that back:  I now have a vague
recollection of it, and I may have just used rcc (which is the AT&T
compiler) to compile the one module that had the asm's.  (I also didn't
think that gcc would take the syntax that dep.c uses, but maybe I'm wrong.)
Anyway, if you choose to go that route, you may need to use the following
flags when compiling any module with rcc: -DM_UNIX -DM_XENIX -DM_I386
-DM_COFF.  I think that will take care of it.

Oh, yeah:  you also won't be able to debug gdb with gdb, if you build it
with gcc.  It gets the debugging information very wrong.

-- 

-----------------+
Sean Eric Fagan  | "Time has little to do with infinity and jelly donuts."
seanf@sco.COM    |    -- Thomas Magnum (Tom Selleck), _Magnum, P.I._
(408) 458-1422   | Any opinions expressed are my own, not my employers'.

seanf@sco.COM (Sean Fagan) writes:

>I've built gdb with the MSC compiler (under SCO UNIX, of course 8-)), and
>don't really remember this.  Well, I take that back:  I now have a vague
>recollection of it, and I may have just used rcc (which is the AT&T
>compiler) to compile the one module that had the asm's.  (I also didn't
>think that gcc would take the syntax that dep.c uses, but maybe I'm wrong.)
>Anyway, if you choose to go that route, you may need to use the following
>flags when compiling any module with rcc: -DM_UNIX -DM_XENIX -DM_I386
>-DM_COFF.  I think that will take care of it.

I don't use the MS cc that comes with SCO, there's too much it gets wrong.

However, I do have a couple of bits re: rcc.  You may also want to include
-DM_SYSV -DSYSV -DNO_PROTOTYPE  as some of the .h files and other UNIX
sources use these.  Also, there is a problem with rcc in that an assignment
like this:
            { char a[6];
              a[6] = NULL;
            }
will overwrite the following couple of bytes as well, as the generated
code is for a move long instead of a move byte.
NOTE: I DON'T WRITE CODE LIKE THAT, it was in ISODE.
stdio.h  defines NULL (void *) 0
interestingly enough, rcc doesn't have any problem with 
               a[6] = (long) 0;
only with
               a[6] = (anything *) 0;
So I also use   -DNULL=0  on the command line to avoid that little
problem.

BTW, rcc does generate a warning before it generates that bad code.
illegal pointer combination op = 
or something like that.


-- 
Lyle                      Wang             lws@comm.wang.com
508 967 2322         Lowell, MA, USA       uunet!comm.wang.com!lws