Xref: utzoo comp.unix.aix:1601 comp.lang.c++:8995
Path: utzoo!attcan!uunet!snorkelwacker!usc!cs.utexas.edu!romp!auschs!awdprime!stingray.austin.ibm.com!marc
From: marc@stingray.austin.ibm.com (Marc J. Stephenson/140000;1C-22)
Newsgroups: comp.unix.aix,comp.lang.c++
Subject: Re: Risc6000 dbx
Keywords: dbx ibm aix unix
Message-ID: <3171@awdprime.UUCP>
Date: 15 Aug 90 15:51:42 GMT
References: <489@norman.UUCP>
Sender: news@awdprime.UUCP
Followup-To: comp.unix.aix
Organization: IBM AWD, Austin
Lines: 58

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