7 Replies Latest reply on May 21, 2012 4:49 PM by Steve.Clamage-Oracle

    sun compiler and gdb

      I would like to debug a Sun Studio 12.2 compiled program using gdb. gdb folks say [1] this should be theoretically possible. However I got two problems depending on gdb version:
      1. Relevant part of dwarfdump:
      <1><80697>     DW_TAG_imported_declaration
                DW_AT_import <0>
      Is this correct? I mean this <0> is somewhat suspicious to me.
      2. Sun Studio 12.2 seems to use several dwarf extensions, eg. DW_AT_SUN_part_link_name. Is there any way (command line switch?) to turn off those extensions?

      [1] http://comments.gmane.org/gmane.comp.gdb.devel/32092
        • 1. Re: sun compiler and gdb
          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 [] claims that: "521 5.0.0 messages are no longer accepted for sun.com" (original e-mail address was: incidentupdatedaemon@sun.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
          • 2. Re: sun compiler and gdb
            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.
            • 3. Re: sun compiler and gdb
              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
              • 4. Re: sun compiler and gdb
                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
                CC -g myprog.cc
                gdb a.out
                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.

                I did not see any complaints about DWARF.
                • 5. Re: sun compiler and gdb
                  Here is how it looks for me:
                  cat test.cpp
                  #include <iostream>

                  using namespace std;

                  int main()
                  int i=0;
                  CC -V
                  CC: Sun C++ 5.11 SunOS_sparc 2010/08/13
                  usage: CC [ options ] files. Use 'CC -flags' for details
                  CC -g test.cpp
                  gdb -readnow ./a.out
                  GNU gdb 6.7.1
                  (copyright info)
                  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]
                  (gdb) quit
                  uname -a
                  SunOS s10host 5.10 Generic_137137-09 sun4u sparc SUNW,Sun-Fire-V490
                  Then where lies the difference...?

                  Edited by: user3222357 on May 11, 2012 6:20 PM
                  • 6. Re: sun compiler and gdb
                    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?
                    • 7. Re: sun compiler and gdb
                      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.