anand@norman.UUCP (Anand Bemra) (08/15/90)
Although I go through comp.unix.aix about 3-4 times a week, I have not come across folks complaining about the dbx on Risc6000. When I get a core dump, I expect the dbx to tell me which function it core dumped in by giving me the stack dump. It should not matter whether or not I had the debug option set when I compiled my source code. The debug option is needed only if I wanted to see where *inside* the function the core dump occured. Another irritating fact of life with Risc6000 is that when I do a 'file core' command, it tells me "core: data" instead of telling me which executable dumped that core. The problem gets worse when you are debugging C++ code. I am using the Oasys 1.2E C++ translator. The stack dump is quite often useless, probably because the dbx cannot figure out the corresponding C function names. I have been unable to cast pointers to a class and print out the values. Most of the time when I do a: print <variable name> I end up getting some hex value instead of getting something more meaningful. Yes, I am refering to the contents of a pointer. Since my development work is usually on a Sun, I am a little spoiled and expect things to work just as they do on Sun or better. And that just isn't the case with the dbx on Risc6000. Another group in my company who work with Pascal (poor souls) cannot even load the core with dbx. The dbx itself core dumps! This happens inspite of increasing the paging space which sometimes helps in loading large executables. All this happens on the "Gold" release of 9021 AIX 3.1
marc@stingray.austin.ibm.com (Marc J. Stephenson/140000;1C-22) (08/15/90)
In article <489@norman.UUCP> anand@norman.UUCP (Anand Bemra) writes: >When I get a core dump, I expect the dbx to tell me which function it >core dumped in by giving me the stack dump. It should not matter whether or not >I had the debug option set when I compiled my source code. >The debug option is needed only if I wanted to see where *inside* the function >the core dump occured. dbx tells you which line or address that your program faulted at startup time. If you want a traceback, just issue the where command after dbx starts up. > >Another irritating fact of life with Risc6000 is that when I do a >'file core' command, it tells me >"core: data" >instead of telling me which executable dumped that core. Okay, here's a way to do this: dbx /etc/passwd. dbx will tell you that the core doesn't match the debuggee, and will give the name of the dumper: Core file program (foo) does not match current program(core ignored) > >The problem gets worse when you are debugging C++ code. I am using the >Oasys 1.2E C++ translator. The stack dump is quite often useless, >probably because the dbx cannot figure out the corresponding C function >names. I have been unable to cast pointers to a class and print out >the values. dbx type casting is somewhat bizarre; it does not accept (in a stock dbx implementation) normal C syntax. To print a char variable c as an int, you can do "print int(c)" or "print c \ int", but not "print (int) c". Also, for tagged types (structs, enums, and unions, and consequently classes) there is a funny $$tag-name syntax to do casting; rather than using "struct foo", you have to use "$$foo". Once again, right out of BSD. Casting pointers is even worse, but that's all documented. >Most of the time when I do a: >print <variable name> >I end up getting some hex value instead of getting something more >meaningful. Yes, I am refering to the contents of a pointer. When you print a pointer, you have to dereference it, except in the case of C char * variables. If x is a pointer to a struct, then "print x" will give a hex value. "print *x" or "print x^" will dereference the variable. That's normal dbx behavior; if SUN or somebody else changed that behavior, then that was their choice. 4.3 BSD dbx works as I described it. > >Another group in my company who work with Pascal (poor souls) cannot >even load the core with dbx. The dbx itself core dumps! This happens >inspite of increasing the paging space which sometimes helps in loading >large executables. > >All this happens on the "Gold" release of 9021 AIX 3.1 Report problems to IBM if you wish to have them corrected. -- Marc Stephenson (marc@stingray.austin.ibm.com) DISCLAIMER: The content of this posting is independent of official IBM position. External: uunet!cs.utexas.edu!ibmaus!auschs!stingray.austin.ibm.com!marc Internal: marc@stingray.austin.ibm.com VNET: MARC at AUSVMQ T/L: 793-3796
madd@world.std.com (jim frost) (08/23/90)
anand@norman.UUCP (Anand Bemra) writes: >Although I go through comp.unix.aix about 3-4 times a week, I have >not come across folks complaining about the dbx on Risc6000. One failure we noticed immediately is that dbx cannot back up beyond a signal hander. Type in the following: -- cut here -- #include <signal.h> int handler() { abort(); } main() { signal(SIGINT, handler); kill(0, SIGINT); } -- cut here -- When dbx gets the abort signal, it cannot back up on the stack beyond handler(). A lot of applications use signal handlers to clean up before leaving on a terminal error (eg SIGSEGV) -- the kind of error that you want to track down -- so this is A Bad Thing. I ran into it in the first few minutes of porting a mid-sized application. I expect that the reason why this is done is that it's difficult to tell if you're in the middle of the function prologue or epilogue when you get the signal, and if you are then some of the information in the stack and/or traceback tables isn't right. It would still be nice to be able to get a full stack trace anyway -- even if the information for the function which was interrupted is not guaranteed correct. This problem exists under 9021F. I haven't tried it yet with the 3001 update installed. jim frost saber software jimf@saber.com
peter@msinc.msi.com (Peter Blemel) (08/24/90)
And dbx core dumps (in 9021) on large programs. Peter
marc@stingray.austin.ibm.com (Marc J. Stephenson/140000;1C-22) (08/24/90)
In article <113@.msinc.msi.com> peter@msinc.msi.com (Peter Blemel) writes: >And dbx core dumps (in 9021) on large programs. > >Peter It doesn't core dump on the 48MB executable example that I have. If it is core dumping, it probably is related to something else other than program size. Report your particular problem. -- Marc Stephenson (marc@stingray.austin.ibm.com) DISCLAIMER: The content of this posting is independent of official IBM position. External: uunet!cs.utexas.edu!ibmaus!auschs!stingray.austin.ibm.com!marc Internal: marc@stingray.austin.ibm.com VNET: MARC at AUSVMQ T/L: 793-3796