libove@ius3.ius.cs.cmu.edu (Jay Libove) (03/18/90)
I've brought the entire GNU debugger (gdb) v3.5 sources down to my SCO Unix SysV v3.2 system running on a generic 80386SX AT-Bus clone type machine ( *whew* ), and though the major part of the code compiles without huge modifications, the readline/ subdirectory/library tickles a bug that is taken care of in the main area - the TIOCGETC_BROKEN thing... I know this isn't a clear description to anyone who hasn't hit exactly the same situation; I'm just hoping that someone out there _has_ hit this same exact situation with SCO Unix 3.2 (386) and gdb (hell, any version! :} ) and can help me... Please reply via email - thanks in advance! -- Jay Libove Internet: libove@cs.cmu.edu 403 Village Green Blvd, Apt 203 BITNET: libove@drycas Ann Arbor, MI 48105 (313) 747-7454
libove@ius3.ius.cs.cmu.edu (Jay Libove) (03/22/90)
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-7454johnl@esegue.segue.boston.ma.us (John R. Levine) (03/22/90)
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."
kph@dustbin.cisco.com (Kevin Paul Herbert) (03/22/90)
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
seanf@sco.COM (Sean Fagan) (03/23/90)
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'.
lws@comm.wang.com (Lyle Seaman) (03/27/90)
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