david@doe.utoronto.ca (David Megginson) (11/04/90)
I have tried using gdb under TOS 1.2 and TOS 1.4, under RTX, Mupfel and standard TOS, in MT-CShell and Gulam. In every configuration, it bombs with the command "symbol-file". Here is what I tried: gcc -gg -c hello.c gcc_ld -o hello.ttp f:\gnu\lib\crt0.o hello.o -lgnu sym_ld -o hello.sym f:\gnu\lib\crt0.o hello.o -lgnu [run gdb] (gdb) exec-file hello.ttp [no problem] (gdb) symbol-file hello.sym [BOMBS!! (2)] When I try it with -g instead of -gg, I get a bogon alert from gcc_ld (it does not write enough symbols) and the executable is buggy, but the "symbol-file" command does not crash (the program will not run, though). What am I doing wrong? The gdb binary is from atari.archive. Thanks. David Megginson -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
dinapoli@rodan.acs.syr.edu (Ron DiNapoli) (02/02/91)
Howdy! I've been having a problem getting GDB to work on my MEGA 4. If I compile with the -gg switch, the resulting symbol files cause gdb to crash when I attempt to load them. If I compile with the -g switch I get the following error message when I attempt to link the executable... Bogon alert! wrote 213 symbols, expected to write 235 I'm not sure about those numbers, but that was the general error message. the executable is produced, and the symbol file created with sym_ld does load properly into gdb. But when I attepmt to run the executable from gdb, I get "Program terminated with code #ffffff95" (again, not sure of the number). Does anyone know how to create good symbol files and good executables??? I can't use the -mshort flag because I need to have 32-bit ints (if that makes a difference). thanks for your help! Ron D.
gjh@hplb.hpl.hp.com (Graham Higgins) (02/04/91)
Ron DiNapoli writes about using GDB: ++ I get "Program terminated with code #ffffff95" (again, not sure of the ++ number). ++ Does anyone know how to create good symbol files and good executables??? ++ I can't use the -mshort flag because I need to have 32-bit ints (if that ++ makes a difference). I've seen both problems experienced by Ron DiNapoli. I've recently been trying to port Elk (a Scheme implementation) to the ST. It compiles up but bombs out with a bus error (2 bombs), so I tried using jrd's GDB to debug it. First reports of GDB indicated that it wouldn't work with GCC 1.37.1, later reports suggested otherwise. My own experience suggests that GDB works fine on the set of test data supplied with jrd's GDB port. However, I've not managed to get it to work properly on the compiled Elk code. I am currently oscillating between gulam and ksh-under-mint. (The Elk code tests the executability of argv[0], for some reason it can't find anything there under gulam but can with ksh, anyway ...) GDB crashes out under KSH when reading symbols from the sym file. Scratch one route. Under gulam, it reads the exec and the sym file OK, arrives at the start after "run", reports "info functions", etc fine, but either 2-bombs out on "cont", or reports "Program terminated with code #ffffff95". Once, I got it to "cont" but it wasn't behaving *anything* like the way it does with the (precompiled) test code set. I chased down Edgar Roeder's uni-sb version of GCC, which has been reported as supporting GDB. Didn't seem to make much difference. CFLAGS were: -gg -O -DGEM -D__NO_INLINE__ -mshort -fcombine-regs -fstrength-reduce -fomit-frame-pointer are any of the above flags inimical to GDB? the .ttp and .sym files were produced .. gcc-ld -o scheme.ttp c:\gnu\lib\gcrt0.o $(O) -lpml16 -lgnu16 sym-ld -r -o scheme.sym c:\gnu\lib\gcrt0.o $(O) -lpml16 -lgnu16 I am using crt0.o and gcrt0.o assembled from the .s files distributed with Eric Smith's Mint libraries. The Mint libraries are not linked in to the Elk code. Grateful for any suggestions. BTW, when GCC compiling under gulam, "make" seems to 2-bomb out after some arbitrary period of happy mass compilation, ditto Ksh but less frequently. Under Ksh, problem seems to go away after the third/fourth round of mass compilation (with -g, without -g, with -gg, without -gg, ad nauseam) but return after a warm boot. Anyone shed any light on this --- I have a suspicion that it's a malloc() problem, but it's outside my field. Cheers, Graham ====== ------------------------------------------------------------------ Graham Higgins | Phone: (0272) 799910 x 24060 Hewlett-Packard Labs | gjh%ghiggins@hpl.hp.co.uk Bristol | gjh%ghiggins@hplb.hpl.hp.com U.K. | ------------------------------------------------------------------ Disclaimer: My opinions above are exactly that, mine and opinions. ------------------------------------------------------------------
ersmith@uwovax.uwo.ca (Eric Smith) (02/05/91)
In article <GJH.91Feb4115042@ghiggins.hpl.hp.com>, gjh@hplb.hpl.hp.com (Graham Higgins) writes: > I am currently oscillating between gulam and ksh-under-mint. (The Elk code > tests the executability of argv[0], for some reason it can't find anything > there under gulam but can with ksh, anyway ...) > Did you try different environment styles under gulam? I have set env_style mw in my gulam.g; this makes most of my programs happy. Another useful alternative (if your code expects environment strings like FOO=\0BAR\0 instead of FOO=BAR\0) is "set env_style bm". > CFLAGS were: > > -gg -O -DGEM -D__NO_INLINE__ -mshort -fcombine-regs -fstrength-reduce > -fomit-frame-pointer > > are any of the above flags inimical to GDB? > Yes, -fomit-frame-pointer. gcc should have warned you that "-gg" and "-fomit-frame-pointer" were incompatible. -- Eric R. Smith email: Dept. of Mathematics ersmith@uwovax.uwo.ca University of Western Ontario ersmith@uwovax.bitnet London, Ont. Canada N6A 5B7 ph: (519) 661-3638
david@doe.utoronto.ca (David Megginson) (02/05/91)
In article <GJH.91Feb4115042@ghiggins.hpl.hp.com> gjh@hplb.hpl.hp.com (Graham Higgins) writes: > >CFLAGS were: > >-gg -O -DGEM -D__NO_INLINE__ -mshort -fcombine-regs -fstrength-reduce >-fomit-frame-pointer > >are any of the above flags inimical to GDB? > I have had some success with gdb under the uni-sb gcc compiler and linker, but I have used gcc -c -g test.c gcc_ld -o test.tos test.o sym_ld -r -o test.sym $GNULIB/crt0.o test.o -lgnu (or something like that). I took a look at the gdb source, and it actually seems to support -g and not -gg (ie. dbx, not the native gdb format). >BTW, when GCC compiling under gulam, "make" seems to 2-bomb out after some >arbitrary period of happy mass compilation, ditto Ksh but less frequently. >Under Ksh, problem seems to go away after the third/fourth round of mass >compilation (with -g, without -g, with -gg, without -gg, ad nauseam) but return >after a warm boot. Anyone shed any light on this --- I have a suspicion that >it's a malloc() problem, but it's outside my field. > Aha! I suspect the 40-folder limit. You should be able to find a fix for it on your local BBS. If you already have foldrxxx.prg (or whatever it's called) installed, raise the number. David -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
ZVD007@DMSWWU1C.BITNET (Ulrich Kuehn) (05/22/91)
First of all I want to thank all who replied. I was told that I have to use the -gg option to get debugging info and then have to use sym-ld. But there is a big problem: when I enter gdb and try to read in the sym-file I get two bombs; searching for a solution, I found, that gdb supports no longer the -gg option, one has to use the -g option. So, I tried that, and gdb doesnt crash, it can set breakpoints and list the source, but when I run the program, it allways receives a signal null and when I try to cont the I get two bombs, but the debugger doesnt crash, the program is just halted. Is there anyone with a solution of this problem? Thanks in advance U.Kuehn
timothyg@ncsa.uiuc.edu (Timothy Gallivan) (05/23/91)
In article <91142.182214ZVD007@DMSWWU1C.BITNET>, Ulrich Kuehn <ZVD007@DMSWWU1C.BITNET> writes: |> First of all I want to thank all who replied. |> |> I was told that I have to use the -gg option to get debugging info and then |> have to use sym-ld. |> But there is a big problem: when I enter gdb and try to read in the sym-file |> I get two bombs; searching for a solution, I found, that gdb supports no |> longer the -gg option, one has to use the -g option. So, I tried that, and |> gdb doesnt crash, it can set breakpoints and list the source, but when I |> run the program, it allways receives a signal null and when I try to cont |> the I get two bombs, but the debugger doesnt crash, the program is just halted. |> Is there anyone with a solution of this problem? |> |> Thanks in advance |> U.Kuehn I second this plea for help (actually my fourth). Regarding the -gg option, I received the following from Jwahar Bammi: >compile your program with -gg -D__NO_INLINE__ and it should hopefully work >gdb is very much out of date. gnu has dropped support for -gg format, >and the latest versions of the assembler dont support the additional >info produced by -gg. one day i'll get around to doing gdb properly. Defining __NO_INLINE__ gets rid of the two bombs, but I also get the null signal. You are supposed to be able to tell gdb to ignore the null signal, but when I try to do this, gdb tells me that 0 (the null is signal number 0) is not a valid signal number. So, I can't change anything. I have about given up on gdb, and have reverted to using Gdb (the Gallivan debugger--lots of print statements!). Tim Gallivan timothyg@ncsa.uiuc.edu