sbw@naucse.UUCP (Steve Wampler) (10/04/88)
What is the current status of gdb and gcc for 3B1
computers? Is anyone consistently running either/both
on a unix-pc with no problems? Someone here was working
on it, but left recently. I'm not certain of the state
of his work in either area, but the last time I tried
gcc on the 3b1, it produced a program that core dumped,
and could not be debugged with gdb.
--
Steve Wampler
{....!arizona!naucse!sbw}tkacik@rphroy.UUCP (Tom Tkacik) (10/05/88)
In article <948@naucse.UUCP> sbw@naucse.UUCP (Steve Wampler) writes: >What is the current status of gdb and gcc for 3B1 >computers? Is anyone consistently running either/both >on a unix-pc with no problems? Someone here was working >on it, but left recently. I'm not certain of the state >of his work in either area, but the last time I tried >gcc on the 3b1, it produced a program that core dumped, >and could not be debugged with gdb. >-- > Steve Wampler > {....!arizona!naucse!sbw} I have both gcc-1.28 and gdb-2.5 running on my 7300. I thought that gcc-1.28 would be stable by now, but I find that it does not correctly generate code to assign an unsigned short to and int. (This is without optimizing; when optimizing, it gets it right). Has anyone else noticed this,or perhaps I have done something wrong. Other times I think it is wrong, (I still don't trust it fully), only to discover that I need to use the -traditional and/or -fwritable-strings options. Being and ANSI-C compiler, (or as close as one gets right now), it does not like certain questionable constructs that people have used in the past. But it seems to be getting to the point where I can recommend it to those who can get their hands on it. Gcc-1.28 is the first version I have had that will compile without changes, though I didn't let that stop me from making some. The version of gdb I have running is due to the kind work of Bob Rose. (Wait a minute, isn't/wasn't Bob Rose at arizona!naucse!rrr? I am glad he gave his diffs out before leaving, so that others might keep working on it.) I have it mainly to see what is so great about it, (I have heard many things). Now that I am used to it, I do see the clear advantages of it over sdb. However, it is far from being stable. It crashes as the most inoportune moments. Compiling it with -g, so that I can debug gdb using gdb (or sdb) makes a very large executable, over 600k. I have found where it crashes and can do tracebacks on the stack, but do not know it well enough yet to try and make any fixes. Bob said that he could use gdb to debug code compiled with cc but not with gcc. Well, now gcc seems to generate proper coff debugging information. And I think that the problems of gdb reading coff files matches those that gcc has in making them, because I have found that it is easier to debug code compiled with gcc, using gdb than sdb. Sdb will occasionally complain about some bad .eb and .bb (begin and end block) constructs. Basically gdb is in working condition, but you will probably spend more time trying to debug gdb than you will in using it. Get it if you would like to work on it. Otherwise, just realize that it is not a production debugger for the UnixPC yet, and use it anyway. Tom Tkacik umix!mcf \ / tetnix!tet uunet!edsews - !rphroy! - megatron!tkacik