This content has been marked as final. Show 7 replies
I have tried contacting Oracle through RFE form, got response that it should work already, wanted to reply (that it does not for me) but unfortunately the mails do not get through as ucsinet40.oracle.com [18.104.22.168] claims that: "521 5.0.0 messages are no longer accepted for sun.com" (original e-mail address was: email@example.com). Any other way to contact the guy (Steve) who wrote to me regarding this issue (Incident Review ID: 2246622)?
Edited by: user3222357 on May 11, 2012 10:15 AM
The bugs.sun.com mechanism for reporting bugs is being phased out. It will be replaced by the standard Oracle bug reporting mechanism as the former Sun groups (like Studio) transition from the old Sun bug database to the Oracle bug database. Look for an announcement in the Forums when the new mechanism is in place.
I replied to the bug report. Briefly, I have no difficulty building a program with -g using Studio CC and running it under gdb, setting breakpoints and stepping through code. Debugging functionality, however, is very limited compared to using dbx.
DWARF provides for vendor-specific additions. Both gcc and Studio use (different) vendor-specific extensions. The Studio extensions allow for much more detailed debugging than gcc/gdb does.
A DWARF client is supposed to ignore vendor-specific extensions that it doesn't understand, so the presence of Studio DWARF extensions should not affect gdb.
If you can post a small example that demonstrates the problem you are having, someone here can have a look at it. Be sure to provide details about the platform you are on, and the versions of Studio and gdb that you are using.
1. You can find all the details (including trivial test code, executable, dwarfdump output, compiler versions, architectures) in the link to discussion on gdb list that I have provided in my first post. Basically I agree that these compiler specific extensions should be ignored by gdb. However it seems they are ignored for you (and then it works correctly), but they are not for me (at least gdb complains about them and does not allow to set breakpoint). Maybe I should be using some specific compiler options, maybe the compiler version we are using is different. I originally tried gdb 7.0.1 and 7.4.1, but seeing that you are using 6.7.1 I also tried that one and still no luck (get an error about unknown attribute).
2. What functions of dbx would I lose by switching to gdb? Debugging (at least for the sake of this discussion) is mostly about stepping through the code, setting breakpoints (of various types) and reading/modifying values of variables. For me the biggest problem with dbx is that is does not integrate with QtCreator. If at least some adapter existed (which would behave like gdb but use dbx inside)...
Edited by: user3222357 on May 11, 2012 2:26 PM
I looked at some of the thread in the gdb forum, and found some usage errors in the examples.
In particular, do not use -xO0 because it is not a documented or supported option. You cannot expect any particular result if you use it.
I ran my test case using Studio 12.2 and 12.3 as
gdb doesn't seem to know how to demangle names for display, and can't find class member functions (probably for the same reason), but can break point on file-level functions.
CC -g myprog.cc gdb a.out
I did not see any complaints about DWARF.
Here is how it looks for me:
Then where lies the difference...?
cat test.cpp#include <iostream>
using namespace std;
CC -VCC: Sun C++ 5.11 SunOS_sparc 2010/08/13
usage: CC [ options ] files. Use 'CC -flags' for details
CC -g test.cppGNU gdb 6.7.1
gdb -readnow ./a.out
This GDB was configured as ""...
Die: DW_TAG_<unknown> (abbrev = 9, offset = 411)
has children: TRUE
DW_AT_name (DW_FORM_string) string: "basic_ostream"
DW_AT_<unknown> (DW_FORM_string) string: "nNbasic_ostream3CTACTB_"
DW_AT_decl_file (DW_FORM_data1) constant: 2
DW_AT_decl_line (DW_FORM_data1) constant: 74
Dwarf Error: Cannot find type of die [in module /login/sg209371/gdbtest/a.out]
uname -aSunOS s10host 5.10 Generic_137137-09 sun4u sparc SUNW,Sun-Fire-V490
Edited by: user3222357 on May 11, 2012 6:20 PM
Any idea what might be the diffrence between our systems? Do you have a gdb version that is compiled from sources provided by gdb team or is it patched in any way? Do you use the exact same compiler version?
The gcc/gdb components I use are built from gcc/gdb source code by an internal Oracle team for use on Solaris. I'm sure that changes to gcc/gdb code are minimal, but I can't say whether there are any changes at all.