Lee_Robert_Willis@cup.portal.com (05/06/91)
re: Comeau C++ and debugging:
Lee Willis> I'm very curious about how and to what extent SAS's CPR can
Lee Willis> be used to debug Comeau's C++ code. (A debugger is a _big_
Lee Willis> issue. I wasn't considering buying your compiler until you
Lee Willis> mentioned that C debuggers could be used)
Greg Comeau> Line number and source file information is retained and that is simply
Greg Comeau> accepted by the C compiler. There is no special trick involved.
Well it sounds pretty magic to me. If I were to create my own language
("LEE++"), and a translater ("LEEfront") which read LEE++ source code,
and spat out C source code, which was then fed through my SAS C
compiler to produce an executable, I would not expect to be able to use
the CPR debugger to debug native LEE++ code. CPR has no way of knowing
that the C code was an _intermediate_ form, and that LEE++ was the actual
source language. (CPR wouldn't know LEE++ from spam)
Lee Willis> Could you post a file which contains some source code, and the
Lee Willis> compiled executable (compiled with debug) so those of us with
Lee Willis> debuggers could try it out for ourselves?
Greg Comeau> I don't see what that would accomplish.
For one, it might convince me to buy your product.
Greg Comeau> ...It is my understanding that
Greg Comeau> others here on the net have Comeau C++ and they are not
Greg Comeau> disputing what I am saying.
No one has confirmed it, either.
If you think I'm confused, you're right. The following excerpts
should explain WHY I'm confused:
John W. Marvin> I assume there is no C++ debugger w/ Comeau?
Greg Comeau> That is currently correct, however it is worth noting that as we
Greg Comeau> currently are telling you to do something like "buy a C compiler
Greg Comeau> too", the result is that you will have a C debugger like CPR and
Greg Comeau> that works fine.
Art Baker> Yes, but...
Art Baker> Using CPR would allow you to look at the C which resulted
Art Baker> from compiling the C++ source code. It would not give you the
Art Baker> ability to debug at the C++ source level. This is a
Art Baker> much-less-than-optimal solution.
Greg Comeau> Not so at all.
Greg Comeau>
Greg Comeau> Using CPR allows you to debug/look at the C++ source
Greg Comeau> _*NOT*_ the intermediate C.
Micheal Rizzo> Another problem is that member function names of
Micheal Rizzo> the form "class::function" get translated to some other C
Micheal Rizzo> function name internally - I don't know for sure but I expect
Micheal Rizzo> this is the case with Comeau C++ (that's how its done on GNU and
Micheal Rizzo> Zortech).
Greg Comeau> That is correct.
^^^^^^^^^^^^^^^^
This doesn't sound like source level debugging to me.
Greg Comeau> ....We find that initial purchasers of
Greg Comeau> Comeau C++ will sometimes call up about this, but often never
Greg Comeau> call twice as they get used to it since C++ has many
Greg Comeau> characteristics which diverts the energy normally spent in
Greg Comeau> debugging into other areas of the programming cycle.
Greg Comeau> Nevertheless, this is something that we spend time on solving
Greg Comeau> with the ports of Comeau C++ we do. For instance, under UNIX we
Greg Comeau> have something called CCsdb, which allows you to use to C++ names
Greg Comeau> as is.
Micheal Rizzo> With older versions of GNU gdb there was a small utility g++filt
Micheal Rizzo> which one could use to translate between C++ and mangled
Micheal Rizzo> identifiers. Used with a mouse cut-and-paste-text-between-windows
Micheal Rizzo> as provided by xterm this was very useful. I believe such a PD
Micheal Rizzo> utility for cutting & pasting text between console windows is
Micheal Rizzo> available for the Amiga so maybe an equivalent of g++filt would
Micheal Rizzo> be nice ?
Greg Comeau> Comeau C++ comes with a utility we call c++filt, c++filt.CC, or
Greg Comeau> comofilt depending upon the port (don't ask we why haven't
Greg Comeau> standardized the name please) that supports just such a
Greg Comeau> demangling capability.
Why would one need a name-demangler if the debugger shows C++ source code?
Do you see my confusion? Based solely on whats posted here on the net,
(which is all the information I currently have) I am forced to conclude
that using CPR to debug C++ is going to give me (at best) some sort of
bastard hybrid environment, where the display shows C++ sometimes, and
name-mangled C at others.
If you post some source code and compiled executables, I can see for
myself.
Lee Lee_Robert_Willis@cup.portal.comdavidm@uunet.UU.NET (David S. Masterson) (05/07/91)
>>>>> On 5 May 91 20:40:35 GMT, Lee_Robert_Willis@cup.portal.com said:
Lee> re: Comeau C++ and debugging:
Lee> Why would one need a name-demangler if the debugger shows C++ source code?
Lee> Do you see my confusion? Based solely on whats posted here on the net,
Lee> (which is all the information I currently have) I am forced to conclude
Lee> that using CPR to debug C++ is going to give me (at best) some sort of
Lee> bastard hybrid environment, where the display shows C++ sometimes, and
Lee> name-mangled C at others.
I think I'm beginning to get the idea of what Greg is saying, but I don't have
C++ yet, so I can't confirm it (I also don't have SAS/C). Basically, what you
said in this paragraph is correct, but, because of the closeness of C and C++,
it may not be as bad as you think. Basically, I'll bet that the compiler uses
what are in the '#line' directives to determine the name and line number of
the source file it is currently processing. This is how the standard C
compiler with a C preprocessor as a separate step works. C++ just does the
same thing that CPP does. CPR would, therefore, know where it is at anytime
in debugging an executable, but, if you ask it about a variable's value, it
would still interpret the name by C conventions. Since you are looking at C++
names (not C names), you have to do a little interpretting for CPR. This
really is not any different than working on YACC and LEX code.
Lee> If you post some source code and compiled executables, I can see for
Lee> myself.
Try creating a fairly large text file (it doesn't matter what's in it) and
then build a C file that has '#line' directives in it that point to the text
file. Compile the C file with debugging on and run it through CPR to see what
it looks like. I'll bet that CPR shows the text file. The difference between
this and C++ is that C++ would be a lot closer to C than the text file, so
stepping through the program would make more sense.
Remember, this is what's available now. If I interpret Greg correctly, things
could only improve. It depends on what you are after, though. An integrated
environment would make building Amiga programs easier, but they might be
specific to a compiler. A C++ to C translator could make moving your program
from system to system easier because you wouldn't need a C++ compiler
everywhere (provided you build your C++ correctly).
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (05/07/91)
As quoted from <42022@cup.portal.com> by Lee_Robert_Willis@cup.portal.com: +--------------- | Greg Comeau> Comeau C++ comes with a utility we call c++filt, c++filt.CC, or | Greg Comeau> comofilt depending upon the port (don't ask we why haven't | Greg Comeau> standardized the name please) that supports just such a | Greg Comeau> demangling capability. | | Why would one need a name-demangler if the debugger shows C++ source code? +--------------- The source code may well be shown from the C++ file, but the stack traceback and other debugger calls that don't hit the C++ source file will be based on the C symbols. This is a standard problem with preprocessor-based languages (you can even get it using C if you are sufficiently devious with your #defines). The problem is, writing a native C++ compiler takes a lot more work and therefore presents the opportunity for a lot more compiler bugs. And it's almost always more expensive (the "almost" mainly because of G++). It's a tradeoff, of course. If possible, your best course of action is to try it out first (both native C++ compilers and cfront-based ones) --- and to check with your pocketbook before buying. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
comeau@ditka.Chicago.COM (Greg Comeau) (05/10/91)
Previous "debugging C++" thread have been expired from this machine
(which is unfortunate since I wanted to address some specific points
some of you made/asked about). Nevertheless, it's created enough
interest that I've felt y'all need an answer.
So. Given:
#include <stdio.h>
int a = -3;
main()
{
printf("hello, world\n");
printf("a=%d\n", a);
}
we generate output like:
#line 1 "c.c"
/* <<Comeau C++ Translator 2.1.0 05/16/90>> */
/* < c.c > */
#line 1 "c.c"
char *__vec_new ();
#line 1 "c.c"
char __vec_delete ();
typedef int (*__vptp)();
struct __mptr {short d; short i; __vptp f; };
#line 1 "c.c"
#line 6 "work:aztec/include/stdarg.h"
typedef char *va_list ;
#line 10 "work:aztec/include/stdio.h"
typedef unsigned long size_t ;
#line 34 "work:aztec/include/stdio.h"
typedef long fpos_t ;
#line 45 "work:aztec/include/stdio.h"
typedef struct __stdio FILE ;
#line 36 "work:aztec/include/stdio.h"
struct __stdio { /* sizeof __stdio == 24 */
unsigned char *_bp__7__stdio ;
unsigned char *_bend__7__stdio ;
unsigned char *_buff__7__stdio ;
unsigned short _flags__7__stdio ;
char _unit__7__stdio ;
unsigned char _bytbuf__7__stdio ;
size_t _buflen__7__stdio ;
unsigned short _tmpnum__7__stdio ;
};
extern struct __stdio _iob [];
#line 3 "c.c"
int a = -3;
extern struct __mptr* __ptbl_vec__c_c_a_[];
#line 76 "work:aztec/include/stdio.h"
extern int printf ();
#line 5 "c.c"
int main (){ _ConStrucT();
#line 6 "c.c"
{
#line 7 "c.c"
printf ( (char *)"hello, world\n") ;
printf ( (char *)"a=%d\n", a ) ;
}
}
#line 9 "c.c"
/* the end */
With the prodding that's been visible here, I went and did a quicky
compile of c.c with como (our command line driver) both with a SAS C
back-end and with as still in-house not released Manx C back-end (surprise!)
with debugging turned on. In the Manx sdb case, it worked like a champ.
In the SAS CPR case it displayed the proper file but appears the the
debugging information contained line number relative to the top of
the generated C file and did not pick up the #line line numbers.
Most likely I did not use the right SAS C debugging switch as I've
yet to see this technique fail yet (and I'm convinced that I did this
before we released the SAS back end one).
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418
Producers of Comeau C++ 2.1
Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421
Voice:718-945-0009 / Fax:718-441-2310huver@amgraf.UUCP (Huver) (05/12/91)
In article <38579@ditka.Chicago.COM>, Greg Comeau says: > ... > So. Given: > #include <stdio.h> > int a = -3; > main() > { > printf("hello, world\n"); > printf("a=%d\n", a); > } > > we generate output like: > [two screens full of C directives/code deleted] [and went on to say that Manx sdb worked like a champ, and SAS cpr didn't work quite right, likely due to "inproper compilation flags".] This guy is getting on my nerves. Where in his example source code is C++? If I write in C++, why would I use printf()?? Quit fooling around and go work on a real C++ debugger. -huver !uunet!amgraf!huver
comeau@ditka.Chicago.COM (Greg Comeau) (05/16/91)
In article <427@amgraf.UUCP> huver@amgraf.UUCP (Huver) writes: >This guy is getting on my nerves. Please forgive me for trying to make a brief, honest answer to the net. I could have easily, and I mean outright *EASILY*, just ignored the whole issue. Instead I think it silly that it's being reduced to net-noise. >Where in his example source code is C++? If I write in C++, why would I >use printf()?? Your question is confusing. I use printf in my C++ code all the time. There are lots of reasons to use printf in C++. To make you happy, if instead I'd changed that line from 'printf("hello, world\n");' to 'cout << "Hello, world\n";' my reported results would have been *EXACTLY* the same. >Quit fooling around and go work on a real C++ debugger. Now that's another issue. - Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ 2.1 Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310
davidbro@microsoft.UUCP (Dave BROWN) (05/17/91)
In article <427@amgraf.UUCP> huver@amgraf.UUCP (Huver) writes: > [and went on to say that Manx sdb worked like a champ, and SAS cpr > didn't work quite right, likely due to "inproper compilation flags".] > >This guy is getting on my nerves. Where in his example source code is >C++? If I write in C++, why would I use printf()?? Because on some implementations of the C++ libraries, cout << "Hello World!\n"; is significantly slower than printf("Hello World!\n"); Besides... Object Oriented Programming is only a design technique. You can do Object Oriented Programming in C, it's just harder. C++ introduces enough syntactic sugar that you don't have to bend over backwards to make the code make sense. I've developed quite a bit of code in C++ (been doing it professionally for over 3 years now), and have only RARELY used the streams code. This is probably because most of the code was written at the systems level -- if I wanted to use files, I called the OS's entry points. Didn't want to link in any more than I had to. >Quit fooling around and go work on a real C++ debugger. With the proper #line directives, nothing extra should be needed (mind you, the names will still be mangled, but they ARE recognizable). I use Glockenspiel C++ and Microsoft C 6.0 with CodeView all the time. Mind you, I haven't tried it with Comeau, Lattice 5.10a and CodeProbe, but at this time it would be futile, given that the Lattice C pre-processor does not generate #line directives. >-huver !uunet!amgraf!huver dave -- Dave Brown ...!uunet!microsoft!davidbro ...ni ssendriew eht tel eW "the night doesn't like it... looks just like your face in the moon to me"