mjy@sdti.UUCP (Michael J. Young) (05/20/88)
In article <7871@alice.UUCP> shopiro@alice.UUCP writes: >I regularly use dbx to debug C++ programs. Setting breakpoints on line >numbers works fine. In order to set breakpoints on functions, or inspect >the values of variables, you need to know the ``mangled'' version of >the name you want to reference.... We've all had to deal with this problem in one way or another. One of the major advantages I see to native-code compilers is the debugging support (i.e., access functions and variables by their unmangled identifiers) that would come with it. >The next version of C++ will >have a canonical ``demangler'' that can be incorporated into future >debuggers. I don't have access to a real C++ source-level debugger (such as the one supplied with G++), but a colleague and I have been thinking about what it takes for a person to be able to unambiguously specify identifiers for setting breakpoints, inspecting variables, etc. I suppose the C++ disambiguating operator (::) can be used for many cases, but what about the following case: overload foo; int foo (int){...} int foo (float){...} int foo (int, int){...} Now say that you want to set a breakpoint at the entry to the third function. How would you tell a debugger which foo you are referring to without resorting to line numbers? The compiler disambiguates these on the basis of arguments rather than scope. How would a debugger do this? Using the output of cfront with a debugger such as dbx, one would simply (!) refer to "_fooFII__" (or something equally obvious). How would you do it with the GNU debugger? -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel: +1 617 443 5779 "Bill & Opus in '88" -- Consider the alternatives!
jss@hector.UUCP (Jerry Schwarz) (05/24/88)
In article <269@sdti.UUCP> mjy@sdti.UUCP (0000-Michael J. Young) writes: > >We've all had to deal with this problem in one way or another. One of >the major advantages I see to native-code compilers is the debugging >support (i.e., access functions and variables by their unmangled identifiers) >that would come with it. > Do not assume that a native-code compiler is neccessarily better than one that uses C as an intermediate. While certain possibilities may be available to a native-code generator that are not possible for a compiler that uses C as an intermediate language, there is no guarantee that a native-compiler will be able to use this flexibility in a way that a debugger can use. You have to look at any particular compiler/debugger system to be sure. Jerry Schwarz
mjy@sdti.UUCP (Michael J. Young) (05/26/88)
In article <10325@ulysses.homer.nj.att.com> jss@hector (Jerry Schwarz) writes: >Do not assume that a native-code compiler is neccessarily better than >one that uses C as an intermediate. While certain possibilities may >be available to a native-code generator that are not possible for a >compiler that uses C as an intermediate language, there is no >guarantee that a native-compiler will be able to use this flexibility >in a way that a debugger can use. You have to look at any particular >compiler/debugger system to be sure. Agreed. What I meant, but did not say very well, was that a native-code compiler would hopefully be bundled with a debugger that understands the language. The problem of a reasonable C++ debugging environment is really independent of the compiler. I just expected that both issues would be addressed simultaneously. Unfortunately, my initial comment about native-code compilers confused the real question that I had, which really has to do with the user interface of C++ debuggers. Frankly, unless we are willing to make major changes to the way linkers work, I don't see how any compiler can avoid encoding type information into public symbols. So the problem of mangled identifiers will not go away. What I would like to see is a debugger that understands the encoding scheme used by the compiler and translates identifiers automatically so that the user never has to see the encoded form. The syntax I see as a user should look identical to the C++ source, so a breakpoint could be set at function foo::foo(int), rather than __foo__ctor_I (or whatever). Overloading makes it very difficult to specify an unambiguous reference. It seems to me that even window-oriented debuggers should allow the user to TYPE an unambigous reference (rather than just point to the right spot in the source). The debugger should also be able to display breakpoint lists without necessarily referring to line numbers or mangled identifiers. Session logs and script files also present a problem, although I suppose someone could use the argument that non-interactive uses don't have to be as intuitive and user-friendly. My initial question was how existing C++ debuggers (such as the one for GNU C++ or Oregon Software C++) handle this. Perhaps a better question is what would the user community like to see in future debuggers? Jonathan Shopiro sent me mail describing how pi works. This sounds like a great start in the right direction. I just wish I could get it. -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel: +1 617 443 5779 "Bill & Opus in '88" -- Consider the alternatives!