* sun compiler and gdb @ 2012-05-03 3:23 Tomasz Grobelny 2012-05-03 6:50 ` Sergio Durigan Junior 0 siblings, 1 reply; 13+ messages in thread From: Tomasz Grobelny @ 2012-05-03 3:23 UTC (permalink / raw) To: gdb Hi all, Should it be possible to debug C++ programs compiled using sun compiler using GDB? If so which debug format should I use? Which versions of the compiler/gdb support such a scenario? Currently the situation looks like this (which does not look very promising): > /opt/solstudio12.2/bin/CC -V CC: Sun C++ 5.11 SunOS_i386 2010/08/13 usage: CC [ options ] files. Use 'CC -flags' for details > /opt/solstudio12.2/bin/CC -g -xdebugformat=dwarf test.cpp > gdb -q ./a.out Reading symbols from /full/path/to/my/a.out...done. (gdb) break fun Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x13b33 [in module /full/path/to/my/a.out] (gdb) break main Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x13b33 [in module /full/path/to/my/a.out] (gdb) run Starting program: /full/path/to/my/a.out [Thread debugging using libthread_db enabled] hello world [Inferior 1 (process 9412 ) exited normally] (gdb) quit > uname -a SunOS solac1 5.10 Generic_137138-09 i86pc i386 i86pc > gdb version is 7.4.1 Any ideas what is wrong here? -- Regards, Tomasz Grobelny ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sun compiler and gdb 2012-05-03 3:23 sun compiler and gdb Tomasz Grobelny @ 2012-05-03 6:50 ` Sergio Durigan Junior 2012-05-03 14:00 ` Tomasz Grobelny 0 siblings, 1 reply; 13+ messages in thread From: Sergio Durigan Junior @ 2012-05-03 6:50 UTC (permalink / raw) To: Tomasz Grobelny; +Cc: gdb On Thursday, May 03 2012, Tomasz Grobelny wrote: > Hi all, > Should it be possible to debug C++ programs compiled using sun compiler > using GDB? If so which debug format should I use? Which versions of the > compiler/gdb support such a scenario? Currently the situation looks like > this (which does not look very promising): Indeed. In a quick search using Google, I found some links reporting that the compiler is kind of broken, probably when it comes to DWARF generation. Anyway, by reading this link: http://netbeans.org/bugzilla/show_bug.cgi?id=89876 especifically in comment #8, I saw that you can try enabling some options in your C++ compiler: -Qoption cg -h_gcc -xO0 -g Also, I saw that passing `-xs' to the compiler might help a bit. But overall, AFAIU, you don't have many options here, unfortunately. However, I'm definitely not an expert in the platform, so maybe someone more experienced will show up and help you further. Good luck. -- Sergio ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sun compiler and gdb 2012-05-03 6:50 ` Sergio Durigan Junior @ 2012-05-03 14:00 ` Tomasz Grobelny 2012-05-09 20:31 ` Tom Tromey 0 siblings, 1 reply; 13+ messages in thread From: Tomasz Grobelny @ 2012-05-03 14:00 UTC (permalink / raw) To: Sergio Durigan Junior; +Cc: gdb On Thu, 03 May 2012 03:49:41 -0300, Sergio Durigan Junior <sergiodj@redhat.com> wrote: > On Thursday, May 03 2012, Tomasz Grobelny wrote: > >> Hi all, >> Should it be possible to debug C++ programs compiled using sun compiler >> using GDB? If so which debug format should I use? Which versions of the >> compiler/gdb support such a scenario? Currently the situation looks like >> this (which does not look very promising): > > Indeed. In a quick search using Google, I found some links reporting > that the compiler is kind of broken, probably when it comes to DWARF > generation. Anyway, by reading this link: > > http://netbeans.org/bugzilla/show_bug.cgi?id=89876 > > especifically in comment #8, I saw that you can try enabling some > options in your C++ compiler: > > -Qoption cg -h_gcc -xO0 -g > > Also, I saw that passing `-xs' to the compiler might help a bit. But > overall, AFAIU, you don't have many options here, unfortunately. > However, I'm definitely not an expert in the platform, so maybe someone > more experienced will show up and help you further. > > Good luck. > Now it looks like this (on sparc as the comment suggested that): > /opt/solstudio12.2/prod/bin/CC -xdebugformat=dwarf -Qoption cg -h_gcc -xO0 -g -xs test.cpp > gdb -q ./a.out Reading symbols from /login/sg209371/a.out...done. (gdb) break main Die: DW_TAG_<unknown> (abbrev 8, offset 0x199) parent at offset: 0x175 has children: TRUE attributes: DW_AT_name (DW_FORM_string) string: "basic_ostream" (is canonicalized) DW_AT_<unknown> (DW_FORM_string) string: "nNbasic_ostream3CTACTB_" (not canonicalized) 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/a.out] (gdb) run Starting program: /login/sg209371/a.out [Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)] hello world Program exited normally. (gdb) quit > This time this is gdb 7.0.1. The question is indeed whether the issue is on compiler side or gdb side. The comments from the link you mentioned are from 2007, I would think that Oracle is capable of fixing a bug in 5 years... Also the dwarfdump shows some sensible information (some symbols, names of the source files). -- Regards, Tomasz Grobelny ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sun compiler and gdb 2012-05-03 14:00 ` Tomasz Grobelny @ 2012-05-09 20:31 ` Tom Tromey 2012-05-09 22:58 ` Tomasz Grobelny 0 siblings, 1 reply; 13+ messages in thread From: Tom Tromey @ 2012-05-09 20:31 UTC (permalink / raw) To: Tomasz Grobelny; +Cc: Sergio Durigan Junior, gdb >>>>> "Tomasz" == Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> writes: tomasz> Die: DW_TAG_<unknown> (abbrev 8, offset 0x199) [...] Tomasz> Dwarf Error: Cannot find type of die [in module /login/sg209371/a.out] Tomasz> This time this is gdb 7.0.1. Tomasz> The question is indeed whether the issue is on compiler side or Tomasz> gdb side. The comments from the link you mentioned are from Tomasz> 2007, I would think that Oracle is capable of fixing a bug in 5 Tomasz> years... Also the dwarfdump shows some sensible information Tomasz> (some symbols, names of the source files). This kind of question can't be answered without more information. It could be a compiler bug, or a gdb bug, or a disagreement about the interpretation of DWARF. If you have a small test case, a dump of the DWARF information might prove helpful. If you only have a large test case, then something more selective could help. For example, in the above you could examine the DWARF for DIE 0x199. gdb just says DW_TAG_<unknown>, which isn't very helpful... but presumably the platform DWARF dumper would do better. Tom ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sun compiler and gdb 2012-05-09 20:31 ` Tom Tromey @ 2012-05-09 22:58 ` Tomasz Grobelny 2012-05-09 23:23 ` Tomasz Grobelny 2012-05-10 13:34 ` Tom Tromey 0 siblings, 2 replies; 13+ messages in thread From: Tomasz Grobelny @ 2012-05-09 22:58 UTC (permalink / raw) To: Tom Tromey; +Cc: Sergio Durigan Junior, gdb [-- Attachment #1: Type: text/plain, Size: 1797 bytes --] On Wed, 09 May 2012 14:30:52 -0600, Tom Tromey <tromey@redhat.com> wrote: >>>>>> "Tomasz" == Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> writes: > > tomasz> Die: DW_TAG_<unknown> (abbrev 8, offset 0x199) > [...] > Tomasz> Dwarf Error: Cannot find type of die [in module > /login/sg209371/a.out] > > Tomasz> This time this is gdb 7.0.1. > > Tomasz> The question is indeed whether the issue is on compiler side or > Tomasz> gdb side. The comments from the link you mentioned are from > Tomasz> 2007, I would think that Oracle is capable of fixing a bug in 5 > Tomasz> years... Also the dwarfdump shows some sensible information > Tomasz> (some symbols, names of the source files). > > This kind of question can't be answered without more information. > I will be happy to provide it (but only for the next two weeks as I will lose access to those solaris machines later). > It could be a compiler bug, or a gdb bug, or a disagreement about the > interpretation of DWARF. > I cannot tell... > If you have a small test case, a dump of the DWARF information might > prove helpful. If you only have a large test case, then something more > selective could help. > A trivial test case attached. Compiled with: CC: Sun C++ 5.11 SunOS_sparc 2010/08/13 > For example, in the above you could examine the DWARF for DIE 0x199. > gdb just says DW_TAG_<unknown>, which isn't very helpful... but > presumably the platform DWARF dumper would do better. > I used dwarfdump from the same directory as the compiler. But still the most important question for me is: is it supposed to work? I understand that there may be bugs on either side, but does the general design of dwarf format/compiler/gdb allow for debugging code generated with sun studio compiler using gdb? -- Regards, Tomasz Grobelny [-- Attachment #2: gdbtest.7z --] [-- Type: application/octet-stream, Size: 69557 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sun compiler and gdb 2012-05-09 22:58 ` Tomasz Grobelny @ 2012-05-09 23:23 ` Tomasz Grobelny 2012-05-10 13:34 ` Tom Tromey 1 sibling, 0 replies; 13+ messages in thread From: Tomasz Grobelny @ 2012-05-09 23:23 UTC (permalink / raw) To: Tom Tromey; +Cc: Sergio Durigan Junior, gdb [-- Attachment #1: Type: text/plain, Size: 453 bytes --] On Thu, 10 May 2012 00:57:56 +0200, Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> wrote: > A trivial test case attached. Compiled with: > CC: Sun C++ 5.11 SunOS_sparc 2010/08/13 > Compilation command line was: CC -g -xdebugformat=dwarf test.cpp Now attached is similar package compiled with the following command line: CC -g -xdebugformat=dwarf -Qoption cg -h_gcc -xO0 -g test.cpp (same compiler; as suggested by Sergio) -- Regards, Tomasz Grobelny [-- Attachment #2: gdbtest.7z --] [-- Type: application/octet-stream, Size: 69729 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sun compiler and gdb 2012-05-09 22:58 ` Tomasz Grobelny 2012-05-09 23:23 ` Tomasz Grobelny @ 2012-05-10 13:34 ` Tom Tromey 2012-05-10 16:38 ` Tomasz Grobelny 1 sibling, 1 reply; 13+ messages in thread From: Tom Tromey @ 2012-05-10 13:34 UTC (permalink / raw) To: Tomasz Grobelny; +Cc: Sergio Durigan Junior, gdb >>>>> "Tomasz" == Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> writes: Tom> If you have a small test case, a dump of the DWARF information might Tom> prove helpful. If you only have a large test case, then something more Tom> selective could help. Tomasz> A trivial test case attached. Compiled with: Tomasz> CC: Sun C++ 5.11 SunOS_sparc 2010/08/13 I think it is a compiler bug. The DWARF (from your second posting) looks like: <1><13b39>: Abbrev Number: 115 (DW_TAG_imported_declaration) <13b3a> DW_AT_import : <0x0> [Abbrev Number: 0] I don't think this is a valid DW_AT_import. Tomasz> But still the most important question for me is: is it supposed Tomasz> to work? I understand that there may be bugs on either side, but Tomasz> does the general design of dwarf format/compiler/gdb allow for Tomasz> debugging code generated with sun studio compiler using gdb? -- Yes, it can work. The overall design is sound. GDB even works around compiler bugs. This, however, can only happen when an interested party patches GDB to do so. In this case you could perhaps add some code to dwarf2read.c:read_import_statement, and maybe a new variant of follow_die_ref_or_sig, to handle this bogus DW_AT_import. After that you'd have to try again and see what other bugs crop up. One way to fully test the DWARF reader is to run with -readnow. This will cause full expansion of all CUs -- so any problems will be caught immediately at startup. Tom ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sun compiler and gdb 2012-05-10 13:34 ` Tom Tromey @ 2012-05-10 16:38 ` Tomasz Grobelny 2012-05-10 17:38 ` Tomasz Grobelny 2012-05-10 20:39 ` Tom Tromey 0 siblings, 2 replies; 13+ messages in thread From: Tomasz Grobelny @ 2012-05-10 16:38 UTC (permalink / raw) To: Tom Tromey; +Cc: Sergio Durigan Junior, gdb On Thu, 10 May 2012 07:33:41 -0600, Tom Tromey <tromey@redhat.com> wrote: >>>>>> "Tomasz" == Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> writes: > > Tom> If you have a small test case, a dump of the DWARF information might > Tom> prove helpful. If you only have a large test case, then something > more > Tom> selective could help. > > Tomasz> A trivial test case attached. Compiled with: > Tomasz> CC: Sun C++ 5.11 SunOS_sparc 2010/08/13 > > I think it is a compiler bug. The DWARF (from your second posting) > looks like: > > <1><13b39>: Abbrev Number: 115 (DW_TAG_imported_declaration) > <13b3a> DW_AT_import : <0x0> [Abbrev Number: 0] > > I don't think this is a valid DW_AT_import. > Do you think that this portion can be just ignored by gdb? > After that you'd have to try again and see what other bugs crop up. > Actually the behaviour on the two machines I have tested on is different. Not yet sure whether this is a problem with compiler architecture (x86 vs sparc) or gdb version (7.4.1 vs. 7.0.1), but it looks like this on sparc/gdb 7.0.1: > gdb -readnow ./a.out.sparc GNU gdb (GDB) 7.0.1 (...) This GDB was configured as "sparc-sun-solaris2.10". Reading symbols from /login/sg209371/gdbtest/a.out.sparc...expanding to full symbols...Die: DW_TAG_<unknown> (abbrev 9, offset 0x1bb) parent at offset: 0x197 has children: TRUE attributes: DW_AT_name (DW_FORM_string) string: "basic_ostream" (is canonicalized) DW_AT_<unknown> (DW_FORM_string) string: "nNbasic_ostream3CTACTB_" (not canonicalized) 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.sparc] (gdb) quit > With the relevant portion of dwarfdump looking like this: <2>< 443> DW_TAG_SUN_class_template DW_AT_name basic_ostream DW_AT_SUN_part_link_name nNbasic_ostream3CTACTB_ DW_AT_decl_file 2 /opt/solstudio12.2/prod/include/CC/Cstd/ostream DW_AT_decl_line 74 Shouldn't unknown tag just be ignored? To me it looks like some compiler specific extension. I searched for other tags that might be compiler specific and here is the list: DW_AT_SUN_cf_kind DW_AT_SUN_comdat_function DW_AT_SUN_command_line DW_AT_SUN_compile_options DW_AT_SUN_func_offsets DW_AT_SUN_language DW_AT_SUN_link_name DW_AT_SUN_part_link_name DW_AT_SUN_pass_with_const DW_AT_SUN_return_with_const DW_AT_SUN_template DW_AT_SUN_vbase DW_AT_SUN_vtable DW_AT_SUN_vtable_abi Are any of these supported or (at least) explicitly ignored by gdb? -- Regards, Tomasz Grobelny ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sun compiler and gdb 2012-05-10 16:38 ` Tomasz Grobelny @ 2012-05-10 17:38 ` Tomasz Grobelny 2012-05-10 20:34 ` Tom Tromey 2012-05-10 20:39 ` Tom Tromey 1 sibling, 1 reply; 13+ messages in thread From: Tomasz Grobelny @ 2012-05-10 17:38 UTC (permalink / raw) To: Tom Tromey; +Cc: Sergio Durigan Junior, gdb On Thu, 10 May 2012 18:37:41 +0200, Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> wrote: > Actually the behaviour on the two machines I have tested on is different. > Not yet sure whether this is a problem with compiler architecture (x86 vs > sparc) or gdb version (7.4.1 vs. 7.0.1), but it looks like this on > sparc/gdb 7.0.1: > It turned out to be a difference between gdb versions. Does there exist any tool that would let me throw out those offending sections from the executable file? -- Regards, Tomasz Grobelny ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sun compiler and gdb 2012-05-10 17:38 ` Tomasz Grobelny @ 2012-05-10 20:34 ` Tom Tromey 0 siblings, 0 replies; 13+ messages in thread From: Tom Tromey @ 2012-05-10 20:34 UTC (permalink / raw) To: Tomasz Grobelny; +Cc: Sergio Durigan Junior, gdb >>>>> "Tomasz" == Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> writes: Tomasz> Does there exist any tool that would let me throw out those offending Tomasz> sections from the executable file? Not that I know of. Tom ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sun compiler and gdb 2012-05-10 16:38 ` Tomasz Grobelny 2012-05-10 17:38 ` Tomasz Grobelny @ 2012-05-10 20:39 ` Tom Tromey 2012-05-10 22:08 ` Tomasz Grobelny 1 sibling, 1 reply; 13+ messages in thread From: Tom Tromey @ 2012-05-10 20:39 UTC (permalink / raw) To: Tomasz Grobelny; +Cc: Sergio Durigan Junior, gdb >>>>> "Tomasz" == Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> writes: Tomasz> Reading symbols from /login/sg209371/gdbtest/a.out.sparc...expanding to Tomasz> full symbols...Die: DW_TAG_<unknown> (abbrev 9, offset 0x1bb) You want DIE 0x1bb... Tomasz> parent at offset: 0x197 ... or perhaps 0x197 ... Tomasz> With the relevant portion of dwarfdump looking like this: Tomasz> <2>< 443> DW_TAG_SUN_class_template But this appears to be DIE 0x443. Tomasz> Shouldn't unknown tag just be ignored? Yes, but I think what is happening is that you have one DIE which uses DW_AT_type to refer to another DIE, and gdb doesn't know what to do with the type DIE. Tomasz> I searched for other tags that might be compiler specific and Tomasz> here is the list: Those are actually attributes; tags would be DW_TAG_something. Tomasz> Are any of these supported or (at least) explicitly ignored by gdb? AFAIK, no Sun extensions to DWARF are supported by gdb. Generally they should be ignored, but as you've seen, there are sometimes exceptions. My impression is that this part of gdb is not heavily tested. Tom ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sun compiler and gdb 2012-05-10 20:39 ` Tom Tromey @ 2012-05-10 22:08 ` Tomasz Grobelny 2012-05-11 16:21 ` Tom Tromey 0 siblings, 1 reply; 13+ messages in thread From: Tomasz Grobelny @ 2012-05-10 22:08 UTC (permalink / raw) To: Tom Tromey; +Cc: Sergio Durigan Junior, gdb On Thu, 10 May 2012 14:39:07 -0600, Tom Tromey <tromey@redhat.com> wrote: >>>>>> "Tomasz" == Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> writes: > > Tomasz> Reading symbols from > /login/sg209371/gdbtest/a.out.sparc...expanding to > Tomasz> full symbols...Die: DW_TAG_<unknown> (abbrev 9, offset 0x1bb) > > You want DIE 0x1bb... > > Tomasz> parent at offset: 0x197 > > ... or perhaps 0x197 ... > > Tomasz> With the relevant portion of dwarfdump looking like this: > Tomasz> <2>< 443> DW_TAG_SUN_class_template > > But this appears to be DIE 0x443. > Actually it is DIE 443(dec) == 1bb(hex) When you posted output from another dwarfdump version it took me a while to figure out that one tool is giving numbers in hex and the other in dec. > Tomasz> Shouldn't unknown tag just be ignored? > > Yes, but I think what is happening is that you have one DIE which uses > DW_AT_type to refer to another DIE, and gdb doesn't know what to do with > the type DIE. > Does the above comment about dec/hex values change your analysis here? > Tomasz> I searched for other tags that might be compiler specific and > Tomasz> here is the list: > > Those are actually attributes; tags would be DW_TAG_something. > Thanks for pointing that out - I am new to DWARF stuff and do not yet see the difference between attribute, tag and die. > Tomasz> Are any of these supported or (at least) explicitly ignored by gdb? > > AFAIK, no Sun extensions to DWARF are supported by gdb. > Generally they should be ignored, but as you've seen, there are > sometimes exceptions. My impression is that this part of gdb is not > heavily tested. > I will have a look it they can somehow be removed... -- Regards, Tomasz Grobelny ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sun compiler and gdb 2012-05-10 22:08 ` Tomasz Grobelny @ 2012-05-11 16:21 ` Tom Tromey 0 siblings, 0 replies; 13+ messages in thread From: Tom Tromey @ 2012-05-11 16:21 UTC (permalink / raw) To: Tomasz Grobelny; +Cc: Sergio Durigan Junior, gdb >>>>> "Tomasz" == Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> writes: Tomasz> Actually it is DIE 443(dec) == 1bb(hex) Tomasz> When you posted output from another dwarfdump version it took me Tomasz> a while to figure out that one tool is giving numbers in hex and Tomasz> the other in dec. How weird. Ok. Tomasz> Does the above comment about dec/hex values change your analysis here? Yeah. The DIE in question has the tag DW_TAG_SUN_class_template. gdb doesn't know about this. I guess we could turn it into an error type or something... but that isn't likely to be useful. It might let you do a little debugging. I suppose you could try it out. Tom ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-05-11 16:21 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-05-03 3:23 sun compiler and gdb Tomasz Grobelny 2012-05-03 6:50 ` Sergio Durigan Junior 2012-05-03 14:00 ` Tomasz Grobelny 2012-05-09 20:31 ` Tom Tromey 2012-05-09 22:58 ` Tomasz Grobelny 2012-05-09 23:23 ` Tomasz Grobelny 2012-05-10 13:34 ` Tom Tromey 2012-05-10 16:38 ` Tomasz Grobelny 2012-05-10 17:38 ` Tomasz Grobelny 2012-05-10 20:34 ` Tom Tromey 2012-05-10 20:39 ` Tom Tromey 2012-05-10 22:08 ` Tomasz Grobelny 2012-05-11 16:21 ` Tom Tromey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).