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