djones@megatest.UUCP (Dave Jones) (02/22/88)
Hello C++ers, I would like to see some more discussion on the topic of interactive debuggers for C++. Topic 1. A while back, I asked what bad things would happen if I hacked cfront so that it does not prefix automatic variables with au0_, etc. Nobody said anything. You may have thought I was jesting. I was serious. Stop me if I'm going to break something. Really. Also cfront changes the field names in structs, prefixing the name of the struct. What if I change it so that it doesn't do that? Topic 2. Of course the reason I want to do that is to make dbx a little easier to use with C++. But dbx has its problems, even for straight C. It's got some bugs. But another problem is that it is a fairly closed program, controlled by the software vendors. An OEM is at their mercy. They *can* be merciful. I recently got some good documentation on the workings of dbx and the dbx-dbxtool interface directly from the vendor. But it came with that ominous warning, "Of course this is subject to change." Indeed some vendors have a history of pulling the rugs out from under OEMs by changing software (and hardware) standards. One leading workstation manufacturer did a big hardware and software change two or three years ago, going from "2's" to "3's". They promised that the 3's and their compatible descendants would become the industry standard. Last year they announced another incompatible line, which they assure us will become the industry standard. Sigh. What I am getting around to is that I would like to see a system-independent interactive debugger. Then the vendors can have interoffice change-the-object- format contests if they wish, and I'll be sitting here fat and happy. To find the locations of things, the debugger would not use the symbol-table of the executable file, but instead would use symbol-tables compiled right into the program through static data-structures created by cfront. Please comment. Dave Jones Megatest Corp. 880 Fox Lane San Jose, CA. 95131 (408) 437-9700 Ext 3227 UUCP: ucbvax!sun!megatest!djones ARPA: megatest!djones@riacs.ARPA
steele@unc.cs.unc.edu (Oliver Steele) (02/23/88)
djones@megatest.UUCP (Dave Jones) writes: >A while back, I asked what bad things would happen if I hacked cfront so >that it does not prefix automatic variables with au0_, etc. >Nobody said anything. You may have thought I was jesting. >I was serious. Stop me if I'm going to break something. Really. int foo; main() { int foo; ::foo = 1; } ---------------------------------------------------------------------------- Oliver Steele ...!uunet!mcnc!unc!steele steele@cs.unc.edu "A sea urchin is the best way to comb the inside of a hairy tube." -- Peter Wolfenden
bs@alice.UUCP (02/23/88)
Megatest Corporation, San Jose, Ca) writes ... > A while back, I asked what bad things would happen if I hacked cfront so > that it does not prefix automatic variables with au0_, etc. > Nobody said anything. You may have thought I was jesting. > I was serious. Stop me if I'm going to break something. Really. > Also cfront changes the field names in structs, prefixing > the name of the struct. What if I change it so that it doesn't do that? Cfront ``mangles'' names of local variables to avoid clashes between different uses of the same name in a local scope. Consider: int i; inline f(int x) { int i = x; x++; return i; } g() { int i = f(::i); } Here the code produced must refer to both f's i, the global i, and g's i in a single expression. Take away the prefixes generated for local names and you generate bad code. I think the proper approach is to have the debuggers understand the encoding strategy so that they can allow the user to use simple names where appropriate and use C++ language level disambiguation, such as ::i, where needed. To make this approach feasible the encoding strategy must be simple, stable, and documented. This is being taken care of. This in itself will not enable you to write a systems independent debugger but it will enable you to give a C debugger a much nicer C++ interface.
bs@alice.UUCP (02/24/88)
Class member names are given prefixes by cfront to make them unique
in a generated struct declaration not to please ancient C compilers
that do not understand non-unique member names in different structs.
An example of the use of class member prefixes for data members:
class A { short a; char aa; public: ... };
class B : public A { char a; public: ... };
Here a B has two members called `a' the C code generated must use
two different names for them. For example:
struct B {
short A_a;
char A_aa;
char B_a;
};
An alternative code generation strategy would generate a member of B
of type `struct A' and avoid the prefixes, but on most machines this
would cause the size of B to increase because of alignment requirements.
I chose to make the 'a's private simply to give a plausible example. djones@megatest.UUCP (Dave Jones) (02/25/88)
in article <1358@thorin.cs.unc.edu>, steele@unc.cs.unc.edu (Oliver Steele) says: > > djones@megatest.UUCP (Dave Jones) writes: >>A while back, I asked what bad things would happen if I hacked cfront so >>that it does not prefix automatic variables with au0_, etc. >>Nobody said anything. You may have thought I was jesting. >>I was serious. Stop me if I'm going to break something. Really. > > int foo; > main() > { > int foo; > > ::foo = 1; > } > Gag. I forgot about ::foo. I've never had occasion to use it. thanks, djones
djones@megatest.UUCP (Dave Jones) (02/25/88)
in article <7711@alice.UUCP>, bs@alice.UUCP says: > > [...] > > I think the proper approach is to have the debuggers understand the encoding > strategy so that they can allow the user to use simple names where > appropriate and use C++ language level disambiguation, such as ::i, where > needed. > Thanks for the reply. Of course what you suggest is not a two line hack. The filter that turns C++ names into the "mangled" C names would need to be rather sophisticated about lexical scope, I think. The reason I am pursuing this is that I am on a small campaign to get my cohorts here to use C++. I have encountered some resistance on the grounds that the debugger would be harder to use. I haven't had any trouble with it, but then I don't use debuggers much. I grew up before they were invented. If you couldn't hack the paper tape with a hole punch and masking tape ... Kids today ... pampered bunch of whining sissies .... grumble ... snort. Got to go now. I'm late for my Geritol. - Dave J.