Very Computer

by **Thomas Rieche** » Thu, 14 May 1998 04:00:00

Hello,

I try to use gdb-4.16 to debugging C++ code compiled with SPARCompiler C++
4.1. The sample source code shows me, that gdb can't demangle the symbols?
I have compiled the gdb, but the result is the same. What's going wrong?

The machine I'm working on is a Sparc Ultra-Enterprise 5000 with Solaris
2.5.1, SunOS 5.5.1. The source code is compiled with "CC -g hello.cpp".

Any idea is welcome!

Thanks in advance,
Thomas

________________________________________________________________________________

#include <iostream.h>

class toout
{
public:
void say_hello();

Quote:};

void toout::say_hello()
{
cout << "Hello world." << endl;

Quote:}

int main(int argc, char** argv)
{
toout a;

a.say_hello();

return 0;

Quote:}

GDB 4.16 (sparc-sun-solaris2.5), Copyright 1996 Free Software Foundation,
Inc...
(gdb) break main
Breakpoint 1 at 0x10bac: file hello.cpp, line 18.
(gdb) run
Starting program: a.out

Breakpoint 1, main (argc=1, argv=0xeffff764) at hello.cpp:18
18 a.say_hello();
(gdb) step
__0fFtooutJsay_hellov (this=0xeffff6fb) at hello.cpp:11
11 cout << "Hello world." << endl;
(gdb) where
#0 __0fFtooutJsay_hellov (this=0xeffff6fb) at hello.cpp:11
#1 0x10bbc in main (argc=1, argv=0xeffff764) at hello.cpp:18
(gdb) quit

by **Gunnar Everman** » Fri, 15 May 1998 04:00:00

> I try to use gdb-4.16 to debugging C++ code compiled with SPARCompiler C++
> 4.1. The sample source code shows me, that gdb can't demangle the symbols?
> I have compiled the gdb, but the result is the same. What's going wrong?

> The machine I'm working on is a Sparc Ultra-Enterprise 5000 with Solaris
> 2.5.1, SunOS 5.5.1. The source code is compiled with "CC -g hello.cpp".

> Any idea is welcome!

use dbx. If you can afford that kind of Hardware you will surely be
able to buy the complete WorkShop package from Sun. :-)

BTW: your CC needs an update. AFAIK the current one is:

CC -V
CC: WorkShop Compilers 4.2 18 Sep 1997 C++ 4.2 patch 104631-04

Gunnar

--

Natural Language Systems Group University of Hamburg, Germany

by **Thomas Rieche** » Fri, 15 May 1998 04:00:00

> use dbx. If you can afford that kind of Hardware you will surely be
> able to buy the complete WorkShop package from Sun. :-)

We currently use dbx. We compile our code with "-xs" option to merge debug
symbols to shared objects, so we can distribute the shared libs without object
files between projects.

The startup time of dbx on those large (shared) objects are immense!
(about 5min to load an application with 76megs of shared libs)

I'm searching for some faster de* -- and the gdb is such a candidate.

Thomas

by **Rodney Leste** » Fri, 15 May 1998 04:00:00

> > I try to use gdb-4.16 to debugging C++ code compiled with SPARCompiler C++
> > 4.1. The sample source code shows me, that gdb can't demangle the symbols?
> > I have compiled the gdb, but the result is the same. What's going wrong?

> > The machine I'm working on is a Sparc Ultra-Enterprise 5000 with Solaris
> > 2.5.1, SunOS 5.5.1. The source code is compiled with "CC -g hello.cpp".

> > Any idea is welcome!

> use dbx. If you can afford that kind of Hardware you will surely be
> able to buy the complete WorkShop package from Sun. :-)

> BTW: your CC needs an update. AFAIK the current one is:

> CC -V
> CC: WorkShop Compilers 4.2 18 Sep 1997 C++ 4.2 patch 104631-04

> Gunnar

> --

> Natural Language Systems Group University of Hamburg, Germany

Ah ha! But Sun now requires you to purchase their "Visual" package to get the
de*
(dbx running within xemacs)! You used to be able to get the compiler and
de* together,
but now you have to get all the BS included in the "Visual C++ Workshop" to have
a
de* and the ability to debug multi-threaded applications (multithreaded
debug licenses
have also been separate).

You used to be able to use gdb or ups with the Sun compilers, but they keep
changing the
symbols format on new releases so you are forced to use theirs.

Why on earth did Sun do this? To make more money?

by **Guenther Gra** » Sat, 16 May 1998 04:00:00

> Ah ha! But Sun now requires you to purchase their "Visual" package to get the
> de*
> (dbx running within xemacs)! You used to be able to get the compiler and
> de* together,
> but now you have to get all the BS included in the "Visual C++ Workshop" to have
> a
> de* and the ability to debug multi-threaded applications (multithreaded
> debug licenses
> have also been separate).

> You used to be able to use gdb or ups with the Sun compilers, but they keep
> changing the
> symbols format on new releases so you are forced to use theirs.

> Why on earth did Sun do this? To make more money?

You can buy the Professional C version which contains the de* dbx
and you have to buy the C++ Workshop to get the C++ compiler. I asked
the SUN people about this stupid arrangement and all they said was
that they aditted it was studid. They said that some people in the
states made a mistake while they were cleaning up different packages SUN
was selling. Now we all have to live with that until they fix it (with
new new upcoming 5.0 release?!)

Guenther

by **Oliver Suc** » Thu, 28 May 1998 04:00:00

Still -- does anybody know if there exists a version of gdb which
understands the binary format (and core) produced by SPARCompiler C++?

-- Oliver

: You can buy the Professional C version which contains the de* dbx
: and you have to buy the C++ Workshop to get the C++ compiler. I asked
: the SUN people about this stupid arrangement and all they said was
: that they aditted it was studid. They said that some people in the
: states made a mistake while they were cleaning up different packages SUN
: was selling. Now we all have to live with that until they fix it (with
: new new upcoming 5.0 release?!)

: Guenther

--
Oliver Suciu

by **Jason Klaps** » Sun, 31 May 1998 04:00:00

Quote:> Still -- does anybody know if there exists a version of gdb which
> understands the binary format (and core) produced by SPARCompiler C++?

> -- Oliver

The problem seems to be related to the interpretation of the 'core file
notes'. I've never seen an answer to this question that actually works-
besides the usually- use dbx with Sun Workshop and other nonsense.
In the light of the lack of responses, I spent sometime one afternoon and
tracked down the area of code that was causing the failure in gdb, and
ignored the return code :) I'm sure I'll hear from someone that that is
not a good idea, but until someone fixes the gdb source, I'll stand by my
hack. Since then, I've been able to gdb cores, and have yet to find a
situation where I've gotten incorrect information during the debugging
process. I'm SURE there is a situation that exercises my hack and will
display junk, but the change seems to work the majority of the time (so
far, all the time for me).
I'm running:
Sun Ultra 170 with Sun C/C++ and latest GNU gcc/g++ w/latest gdb src

The Carrot and the Stick:
Don't have the src handy here- if you would like the patch, let me know
and I will dig it out. If you find another solution, please post it too.
I would like a true fix vs the hack. I just haven't had the time to
pickup the details of the core file format yet :) Best response will be
email, as I don't read this newsgroup often enough. Make sure to remove
the 'obvious junk' from my email address though...

-Jason

Very Computer

gdb with SPARCompiler C++ 4.1

gdb with SPARCompiler C++ 4.1

gdb with SPARCompiler C++ 4.1

gdb with SPARCompiler C++ 4.1

gdb with SPARCompiler C++ 4.1

gdb with SPARCompiler C++ 4.1

gdb with SPARCompiler C++ 4.1

gdb with SPARCompiler C++ 4.1