bjb@pyramid.pyramid.com (Bruce Beare) (09/19/89)
The think C 4.0 debugger is not able to show stack variables for functions that are 1 or more calling frames "up" the stack. For instance, put a breakpoint at the the severe error code in the errors class and execute some code that creates a window with a WINDid that is not in the project resource file. Your stack trace would look something like: Cobjectsdir: Iobjectsdir CTearoffMenu:Itearoffmenu ----> Cwindow:Iwindow | CheckResource | CError:SevereMacError | | The Cwindow:Iwindow stack frame calls CheckResource just after a call of GetResource('WIND', WINDid). Since WINDid was not in the resource file, the CheckResource will call SevereMacError. My complaint is that I can't use the "data" window to look at the value of WINDid in Cwindow:Iwindow - because it is a stack variable. This behavior of LSC's Debugger is silly. It has all of the information it needs - it knows the stack offset of WINDid (it can display it if we put a breakpoint in the function Cwindow:Iwindow - before calling CheckResource), and it knows how to trace through the stack frames. It just doesn't bother to display the information. I've discussed this with Think's support - Darell (sp?), and he has agreed that this "would be a useful feature" and might be looked at in a future release. My intention here is to raise the point for discussion and hopefully convince Think that it is a real deficiency that should be addressed soon. Bruce Beare
fjo@cbnewsc.ATT.COM (frank.j.owen) (09/21/89)
From article <85031@pyramid.pyramid.com>, by bjb@pyramid.pyramid.com (Bruce Beare): > > My complaint is that I can't use the "data" window to look at the > value of WINDid in Cwindow:Iwindow - because it is a stack variable. > This behavior of LSC's Debugger is silly. It has all of the information > it needs - it knows the stack offset of WINDid (it can display it if > we put a breakpoint in the function Cwindow:Iwindow - before calling > CheckResource), and it knows how to trace through the stack frames. I agree wholeheartedly! It is VERY nice to be able to see the local variables of all routines in the stack frame. You should also be able to display the arguements that were passed to those routines. (Afterall, they are on the stack too.) Register variables are a bit more tricky, but also do-able, since the stack frame also contains saved values of the registers used. The debugger I use here at work (a non-Mac project) has all this and it is VERY VERY helpful. Is Rich Siegel listening? -- Frank Owen 312-982-2182 AT&T Bell Laboratories 5555 Touhy Ave., Skokie, IL 60077 PATH: ...!att!ihc!fjo
awd@dbase.UUCP (Alastair Dallas) (09/23/89)
In article <85031@pyramid.pyramid.com>, bjb@pyramid.pyramid.com (Bruce Beare) writes: > The think C 4.0 debugger is not able to show stack variables for > functions that are 1 or more calling frames "up" the stack. > > <example deleted> > > This behavior of LSC's Debugger is silly. It has all of the information > it needs - it knows the stack offset of WINDid (it can display it if > we put a breakpoint in the function Cwindow:Iwindow - before calling > CheckResource), and it knows how to trace through the stack frames. > It just doesn't bother to display the information. > > I've discussed this with Think's support - Darell (sp?), and he has agreed > that this "would be a useful feature" and might be looked at in a future > release. My intention here is to raise the point for discussion and > hopefully convince Think that it is a real deficiency that should be > addressed soon. > > Bruce Beare Does the word 'scope' ring a bell here? K&R, 1st Ed., p. 76: "The scope of a name is the part of the program over which the name is defined. For an automatic variable declared at the beginning of a function, the scope is the function in which the name is declared, and variables of the same name in different functions are unrelated. The same is true of the arguments of the function." Darell's reaction sounds like good salesmanship, but it also demonstrates why tech support doesn't write the software. Maybe I'm being unnecessarily harsh, but how about a law that says that before Symantec can sell someone a C compiler that that person has to demonstrate competency in the language. No, I take it back--that's not nice. Scoping rules are a fairly advanced part of C and the issue is further clouded by Pascal's nested blocks--that is: function what var x:integer function who GetResource(x) In pascal, the debugger can tell you what 'x' is inside 'who'. C just doesn't work like that. Let's move discussion of radical changes to the C language out of this newsgroup (rec.humor?). I'm sorry; I apologize in advance if I'm being offensive. Call it my mood today and the way this posting hit me. I'll feel better after the weekend. /alastair/
pane@cat.cmu.edu (John Pane) (09/23/89)
In article <244@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: >In article <85031@pyramid.pyramid.com>, bjb@pyramid.pyramid.com (Bruce Beare) writes: >> The think C 4.0 debugger is not able to show stack variables for >> functions that are 1 or more calling frames "up" the stack. >> >> <example deleted> >> >> >Does the word 'scope' ring a bell here? K&R, 1st Ed., p. 76: >"The scope of a name is the part of the program over which the name is... This has nothing to do with rules of scope. When a program is running, the state of the program includes variables that are in all of the active call stack frames. It is perfectly reasonable to expect a debugger to allow the programmer to inspect these values, and in fact most debuggers do. John Pane pane@cs.cmu.edu School of Computer Science Carnegie Mellon University (412) 268-5884 -- John Pane pane@cs.cmu.edu School of Computer Science Carnegie Mellon University (412) 268-5884 -- John Pane pane@cs.cmu.edu School of Computer Science Carnegie Mellon University (412) 268-5884
siegel@endor.harvard.edu (Rich Siegel) (09/23/89)
In article <244@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: >In article <85031@pyramid.pyramid.com>, bjb@pyramid.pyramid.com (Bruce Beare) writes: >> The think C 4.0 debugger is not able to show stack variables for >> functions that are 1 or more calling frames "up" the stack. >> >> This behavior of LSC's Debugger is silly. It has all of the information >> it needs - it knows the stack offset of WINDid (it can display it if >> we put a breakpoint in the function Cwindow:Iwindow - before calling >> CheckResource), and it knows how to trace through the stack frames. >> It just doesn't bother to display the information. (In advance, please excuse any rampant sarcasm. I'm having a tough time.) It's quite clear that you didn't consider all of the issues before posting your article. For example: The debugger is able to do its trace of the procedure call chain by examining return addresses, not by examining stack frames? Why? Simple: not all routines generate a LINK/UNLK pair; if a function has no arguments, no local variables, and no compiler-generated temps, then there will be no LINK/UNLK pair, and therefore there's no way to trace the call chain for that routine. Hence, the debugger traces return addresses instead of A6 frames. Furthermore, it's currently impossible to find variables in frames other than the current activation. Why? Because if the variable is allocated in a register, it's been saved *somewhere* on the stack by a MOVEM instruction. Currently, the compiler does not retain the information as to where the saved registers are, or what they are, and there's no heuristic that the debugger can apply in order to find the saved registers. Non-register variables can't be examined either, for similar reasons; the debugger hasn't a clue as to where the saved A6 is, or even if there is one. "But THINK Pascal can do it,", I hear you say. Quite true, but THINK Pascal's fundamentally different in its architecture - both in the way it maintains its debugging information, and in the way that the debugger works. Several informed design decisions were made for the THINK C debugger, and they were good ones. I agree that it's inconvenient to not be able to display non-local variables, and I've tried to explain why, given that the reasoning you presented is incorrect. R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "There is no personal problem which cannot be solved by sufficient application of high explosives." ~~~~~~~~~~~~~~~
bjb@pyramid.pyramid.com (Bruce Beare) (09/25/89)
In article <244@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: >In article <85031@pyramid.pyramid.com>, bjb@pyramid.pyramid.com (Bruce Beare) writes: >> The think C 4.0 debugger is not able to show stack variables for >> functions that are 1 or more calling frames "up" the stack. >> >> <example deleted> >> >> This behavior of LSC's Debugger is silly. It has all of the information >> it needs - it knows the stack offset of WINDid (it can display it if >> we put a breakpoint in the function Cwindow:Iwindow - before calling >> CheckResource), and it knows how to trace through the stack frames. >> It just doesn't bother to display the information. >> >> I've discussed this with Think's support - Darell (sp?), and he has agreed >> that this "would be a useful feature" and might be looked at in a future >> release. My intention here is to raise the point for discussion and >> hopefully convince Think that it is a real deficiency that should be >> addressed soon. >> >> Bruce Beare > >Does the word 'scope' ring a bell here? K&R, 1st Ed., p. 76: > >"The scope of a name is the part of the program over which the name is >defined. For an automatic variable declared at the beginning of a function, >the scope is the function in which the name is declared, and variables of >the same name in different functions are unrelated. The same is true of >the arguments of the function." > >Darell's reaction sounds like good salesmanship, but it also demonstrates >why tech support doesn't write the software. > >Maybe I'm being unnecessarily harsh, but how about a law that says that >before Symantec can sell someone a C compiler that that person has to >demonstrate competency in the language. No, I take it back--that's not >nice. Scoping rules are a fairly advanced part of C and the issue is >further clouded by Pascal's nested blocks--that is: > > function what > var x:integer > > function who > GetResource(x) > >In pascal, the debugger can tell you what 'x' is inside 'who'. C just >doesn't work like that. Let's move discussion of radical changes to >the C language out of this newsgroup (rec.humor?). > >I'm sorry; I apologize in advance if I'm being offensive. Call it my >mood today and the way this posting hit me. I'll feel better after the >weekend. > >/alastair/ I am not sure exactly what position you are taking. I think that you are saying "If the program can't see the variable from the current PC, then the debugger should not be able to display it." If this is not your position, I'll "apologize in advance." I certainly don't agree with the above statement. 1) The debugging programmer needs all the help that they can get. 2) The "context argument" can be turned around for the purposes of this argument. i.e. "The debugger should be able to set the context in which the memory display/modify request in the data window will be interpreted/executed." This means that when you do a "set context" on a line in the data window, the line will obey all of the scope rules for the selected context.
bjb@pyramid.pyramid.com (Bruce Beare) (09/25/89)
In article <2693@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >In article <244@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: >>In article <85031@pyramid.pyramid.com>, bjb@pyramid.pyramid.com (Bruce Beare) writes: >>> The think C 4.0 debugger is not able to show stack variables for >>> functions that are 1 or more calling frames "up" the stack. >>> >>> This behavior of LSC's Debugger is silly. It has all of the information >>> it needs - it knows the stack offset of WINDid (it can display it if >>> we put a breakpoint in the function Cwindow:Iwindow - before calling >>> CheckResource), and it knows how to trace through the stack frames. >>> It just doesn't bother to display the information. > >(In advance, please excuse any rampant sarcasm. I'm having a tough time.) > >It's quite clear that you didn't consider all of the issues before posting >your article. For example: > > The debugger is able to do its trace of the procedure call chain by >examining return addresses, not by examining stack frames? Why? Simple: not >all routines generate a LINK/UNLK pair; if a function has no arguments, no >local variables, and no compiler-generated temps, then there will be >no LINK/UNLK pair, and therefore there's no way to trace the call chain >for that routine. Hence, the debugger traces return addresses instead of >A6 frames. > > Furthermore, it's currently impossible to find variables in frames >other than the current activation. Why? Because if the variable is allocated >in a register, it's been saved *somewhere* on the stack by a MOVEM instruction. >Currently, the compiler does not retain the information as to where the >saved registers are, or what they are, and there's no heuristic that the >debugger can apply in order to find the saved registers. Non-register >variables can't be examined either, for similar reasons; the debugger >hasn't a clue as to where the saved A6 is, or even if there is one. > >"But THINK Pascal can do it,", I hear you say. Quite true, but THINK Pascal's >fundamentally different in its architecture - both in the way it maintains >its debugging information, and in the way that the debugger works. Several >informed design decisions were made for the THINK C debugger, and they >were good ones. > >I agree that it's inconvenient to not be able to display non-local variables, >and I've tried to explain why, given that the reasoning you presented is >incorrect. > >R. > > > >~~~~~~~~~~~~~~~ > Rich Siegel > Staff Software Developer > Symantec Corporation, Language Products Group > Internet: siegel@endor.harvard.edu > UUCP: ..harvard!endor!siegel > >"There is no personal problem which cannot be solved by sufficient >application of high explosives." > >~~~~~~~~~~~~~~~ No Rich, I did not research how the compiler handles its calling sequence. I did/do not feel that it is necessary. If the compiler does not leave enough information around for the debugger to determine what is going on, I can suggest a simple solution - fix the compiler to provide the required information. Bruce Beare
fjo@cbnewsc.ATT.COM (frank.j.owen) (09/25/89)
From article <244@dbase.UUCP>, by awd@dbase.UUCP (Alastair Dallas): > > Does the word 'scope' ring a bell here? K&R, 1st Ed., p. 76: > > Darell's reaction sounds like good salesmanship, but it also demonstrates > why tech support doesn't write the software. > > Maybe I'm being unnecessarily harsh, but how about a law that says that > before Symantec can sell someone a C compiler that that person has to > demonstrate competency in the language. No, I take it back--that's not Yeh, How 'bout it Alastair? How 'bout another law that says that people demonstrating INcompetency in a language (like yourself) be fined for spreading MISINFORMATION! Bruce Beare was completely correct in expecting a debugger to be able to display the local variables of functions that are stacked up in the current calling sequence. All the variables of each function are in the stack frame for that function and CAN be displayed and even modified. Of course you must in some way tell the debugger WHICH stack frame you are talking about, in case there are locals of different functions with the same name, but that is a do-able thing. (Perhaps THINK's debugger could use hierarchical menus - the second level could have entries for each local.) Many debuggers allow you to do this. It is a VERY nice feature. Please do a little homework before reprimanding others on the net! -- Frank Owen 312-982-2182 AT&T Bell Laboratories 5555 Touhy Ave., Skokie, IL 60077 PATH: ...!att!ihc!fjo
fjo@cbnewsc.ATT.COM (frank.j.owen) (09/25/89)
From article <2693@husc6.harvard.edu>, by siegel@endor.harvard.edu (Rich Siegel) > > (In advance, please excuse any rampant sarcasm. I'm having a tough time.) > > It's quite clear that you didn't consider all of the issues before posting > your article. For example: > > The debugger is able to do its trace of the procedure call chain by > examining return addresses, not by examining stack frames? Why? Simple: not > all routines generate a LINK/UNLK pair; if a function has no arguments, no > local variables, and no compiler-generated temps, then there will be > no LINK/UNLK pair, and therefore there's no way to trace the call chain > for that routine. Hence, the debugger traces return addresses instead of > A6 frames. Wait a minute! I'll grant you that if there is no stack frame, you must just look at the return address, but if there IS a stack frame, isn't the return address IN the stack frame? The debugger MUST be extracting the return address from all the other things in the stack, so it must know SOMETHING about the stack frames! > > Furthermore, it's currently impossible to find variables in frames > other than the current activation. Why? Because if the variable is allocated > in a register, it's been saved *somewhere* on the stack by a MOVEM > instruction. > Currently, the compiler does not retain the information as to where the I think IF the compiler generated enough information, the debugger SHOULD be able to match up all the stuff on the stack correctly. It may be true that the CURRENT debugger can't do these things because the CURRENT compiler doesn't give it enough information, but that is no excuse. Change the compiler. I think that the feature described in the original posting is a useful and valid one. Other compiler/debuggers (I don't know of any in the Mac arena - perhaps the Aztec sdb) have this feature. It IS doable. If there are "other issues to consider" that is your job. We just want the feature. We don't really care what it takes. -- Frank Owen 312-982-2182 AT&T Bell Laboratories 5555 Touhy Ave., Skokie, IL 60077 PATH: ...!att!ihc!fjo
awd@dbase.UUCP (Alastair Dallas) (09/26/89)
In article <85347@pyramid.pyramid.com>, bjb@pyramid.pyramid.com (Bruce Beare) writes: > > (referring to my response) > I am not sure exactly what position you are taking. I think that you are > saying "If the program can't see the variable from the current PC, then > the debugger should not be able to display it." Yes, you're right; that's what I'm saying. I expect a source-level debugger to show me the value of variables which are in context. If the program can't see a variable in a particular context, I don't expect that the debugger can, either. > I certainly don't agree with the above statement. > 1) The debugging programmer needs all the help that they can get. > 2) The "context argument" can be turned around for the purposes of this > argument. i.e. "The debugger should be able to set the context > in which the memory display/modify request in the data window > will be interpreted/executed." This means that when you do a > "set context" on a line in the data window, the line will > obey all of the scope rules for the selected context. I thought about this after I posted my reply: You didn't seem confused that the program context hid the variable, you were upset that the debugger wasn't magical enough. That's certainly a valid addition to the wish list, so I retract my snide comments about not buying C compilers unless you know C. I guess our only continuing disagreement, then, is where to put a global- context debugger on the priority list. It seems like a lot of pain for only a little gain, to me, so I'd put it fairly low on the list. /alastair/
jwright@atanasoff.cs.iastate.edu (Jim Wright) (09/26/89)
Even though this breaks a much beloved tradition on c.s.m.p., I'm not flaming anyone... In article <3424@cbnewsc.ATT.COM> fjo@cbnewsc.ATT.COM (frank.j.owen) writes: | All the variables of each function are in the stack frame | for that function and CAN be displayed and even modified. Of course you | must in some way tell the debugger WHICH stack frame you are talking about, | in case there are locals of different functions with the same name, but | that is a do-able thing. How should recursive functions be handled? Are they a special case at all? Do you really want to allow local variables be changed in calling functions? -- Jim Wright jwright@atanasoff.cs.iastate.edu
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (09/26/89)
In article <254@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: >I guess our only continuing disagreement, then, is where to put a global- >context debugger on the priority list. It seems like a lot of pain for >only a little gain, to me, so I'd put it fairly low on the list. I guess you must never (or seldom) play with recursive functions, such as ray tracers or equation solvers. It's nice to know how you got where you are when the stack overflows. BTW: I can do this just fine with Jasik's Debugger and MPW. Marc Kaufman (kaufman@Neon.stanford.edu)
oster@dewey.soe.berkeley.edu (David Phillip Oster) (09/26/89)
In article <1563@atanasoff.cs.iastate.edu> jwright@atanasoff.cs.iastate.edu.UUCP (Jim Wright) writes: >How should recursive functions be handled? Are they a special case at all? >Do you really want to allow local variables be changed in calling functions? Just handle this problem the same way it is already handled: you set a context in the program window by using the pop-up menu at the bottom of the window. If you enter variable names in the data window, they are interpreted in the program window's current context. Since the compiler generated the code in the first place, it is easy for it to remember whther there is a stack frame, and as for register variables, a simple integer remembers them, since they are allocated sequentially. At the worst, you could add a single bit for "this frame is too complex to remember". A debugger that let me look at variables up the stack is still better than what I've got. While you are at it: how about letting me save the debugger state in a file, so I can reload it when I run the program again, and have the debugger know what files and what variables I was looking at, and what breakpoints I set. How about treating the parameter list of a procedure, and the set of local variables of a procedure as a pseudo-struct, so I can look at the whole set of them in their own window, as I look at structs now. In fact, this would be a reasonable interpretation of typing a procedure name into the data window, in that procedure's context: it would have the value "stack frame 0x0000", and double clicking on it would bring up a stack-like window of all the locals and parameters. Many lisp debuggers work this way. As it stands, the popup menu at the bottom of the program window is really an annoying feature: I can point at nested stack frames, but having pointed at them the debugger won't let me do anything meaningful with them. Also, how about debug time variables or at least macros, so I don't have to refer to a structure as (**(**(**(**foo).fum).fie).fazzle).fop simply because my progragram doesn't happen to assign (**(**(**foo).fum).fie).fazzle to a variable. I should be able to assign it to a variable, say "piggins" at debug time, so I could just type (**piggins).fop rather than the whole tedious expression. I'd even be happy if it were really a macro, and not a true variable. Also, how about making the debugger trust the Make command: if I use the make command to tell the compiler that I know fiels a.c, b.c, and c.c weren't really modified by a change to a .h file, the debugger doesn't believe me and refuses to let me debug any functions in those files until I do a full recompile. Why? Don't get me wrong, I still think it is a great debugger, I just wish that Lightspeed C version 4 had improved on it a little.
rang@cs.wisc.edu (Anton Rang) (09/26/89)
In article <1563@atanasoff.cs.iastate.edu> jwright@atanasoff.cs.iastate.edu (Jim Wright) writes: >In article <3424@cbnewsc.ATT.COM> fjo@cbnewsc.ATT.COM (frank.j.owen) writes: >| All the variables of each function are in the stack frame >| for that function and CAN be displayed and even modified. Of course you >| must in some way tell the debugger WHICH stack frame you are talking about, >| in case there are locals of different functions with the same name, but >| that is a do-able thing. > >How should recursive functions be handled? Are they a special case at all? If you have some way to point at a stack frame, there isn't much of a problem with this. The easiest thing would be a pop-up menu (I gather there is one already from some other discussion). "Up" and "Down" commands to move up and down the stack would be nice. >Do you really want to allow local variables be changed in calling functions? If the compiler does good optimization, changing non-local variables is a big no-no. Why? Because other values in the routine could depend on them. For instance, n = 8; for (i=1; i<=n+2; i++) call_some_function(); The compiler could figure out that n+2 can be computed outside of the loop, and stick it in a register. Changing N will then not change N+2. Of course, you could always turn off optimizations if you're debugging, but this is...well, not necessarily good. It might be nice to just to warn the programmer: "If you change a variable which is not local to the current procedure, bad things may happen." Actually, it shouldn't be too hard to implement a multiple-context debugger. The compiler has to generate a mapping of what variables are in which register, and which registers are saved on the stack, at the time of a function call. This should be enough information for the debugger to walk back up the stack, "restoring" registers so that it can figure out what their values would be after some call returns (and thus when that function's context is reentered). +----------------------------------+------------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | | University of Wisconsin--Madison | | +----------------------------------+------------------+ "You are in a twisty little maze of Unix versions, all different."
dorner@pequod.cso.uiuc.edu (Steve Dorner) (09/26/89)
In article <254@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: >I guess our only continuing disagreement, then, is where to put a global- >context debugger on the priority list. It seems like a lot of pain for >only a little gain, to me, so I'd put it fairly low on the list. It seems to me that when a program does SOMETHING BAD, the causes (or at least the "triggers") are often well back in the stack. Not being able to view contexts other than the current one is a big problem. As a simple example, suppose your program dies because you passed a bad parameter to a function; inside the function, you can say, "that sure is a ROTTEN parameter", but that's all. Being able to peek up the program's metaphorical skirt may show you WHY you passed such a worthless parameter in the first place. Definitely an essential feature. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765
fjo@cbnewsc.ATT.COM (frank.j.owen) (09/26/89)
From article <1563@atanasoff.cs.iastate.edu>, by jwright@atanasoff.cs.iastate.edu (Jim Wright): > How should recursive functions be handled? Are they a special case at all? > Do you really want to allow local variables be changed in calling functions? Recursive functions do NOT need to be handled specially. The PRESENT debugger will show each seperate instance of the function that appears in the current calling chain. They are all listed with the same name if we are looking at recursive invocations. You are probably right that it may not be a prudent thing to change local variables in a called function, but this is a debugger we are talking about. It should let you do alot of things that may not (or perhaps may) be prudent. I have personally found it very useful to at least be able to LOOK at the local variables of both the calling and called functions. They can tell you alot about the state of the machine when a call was made. -- Frank Owen 312-982-2182 AT&T Bell Laboratories 5555 Touhy Ave., Skokie, IL 60077 PATH: ...!att!ihc!fjo
bjb@pyramid.pyramid.com (Bruce Beare) (09/26/89)
In article <1563@atanasoff.cs.iastate.edu> jwright@atanasoff.cs.iastate.edu.UUCP (Jim Wright) writes: >Even though this breaks a much beloved tradition on c.s.m.p., I'm not >flaming anyone... > >In article <3424@cbnewsc.ATT.COM> fjo@cbnewsc.ATT.COM (frank.j.owen) writes: >| All the variables of each function are in the stack frame... > >How should recursive functions be handled? Are they a special case at all? >Do you really want to allow local variables be changed in calling functions? > >-- >Jim Wright >jwright@atanasoff.cs.iastate.edu Recursive functions should not be a special case. The debugger already has a graphical interface to select the stack frame that is desired. "Simply" select the particular call to the function as desired. Bruce Beare
bjb@pyramid.pyramid.com (Bruce Beare) (09/26/89)
In article <254@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: >In article <85347@pyramid.pyramid.com>, bjb@pyramid.pyramid.com (Bruce Beare) writes: >> >> (responses and etc deleted) > >I thought about this after I posted my reply: You didn't seem confused that >the program context hid the variable, you were upset that the debugger wasn't >magical enough. That's certainly a valid addition to the wish list, so >I retract my snide comments about not buying C compilers unless you know C. >I guess our only continuing disagreement, then, is where to put a global- >context debugger on the priority list. It seems like a lot of pain for >only a little gain, to me, so I'd put it fairly low on the list. > >/alastair/ This is where we "really" differ. Without this feature, a debugging programmer can be reduced to either putting "printf's" in the code, or even worse, to iterative debugging -- place a breakpoint, find a problem, place an earlier breakpoint, re-run the code to find the value of a variable in the caller, etc... This can (obviously) be tedious and can greatly slow the debug cycle. When I realized that this was a missing feature - and not a user-error, I was astounded. This is the first symbolic C debugger that I have seen that can't do this (i.e. sdb, dbx, cdb, etc). Think C does a really great job with many things - it shouldn't be second class in the debugger department. Bruce Beare
awd@dbase.UUCP (Alastair Dallas) (09/27/89)
In article <3425@cbnewsc.ATT.COM>, fjo@cbnewsc.ATT.COM (frank.j.owen) writes: > I think IF the compiler generated enough information, the debugger > SHOULD be able to match up all the stuff on the stack correctly. > It may be true that the CURRENT debugger can't do these things because > the CURRENT compiler doesn't give it enough information, but that is > no excuse. Change the compiler. > > I think that the feature described in the original posting is a > useful and valid one. Other compiler/debuggers (I don't know of any in the Mac > arena - perhaps the Aztec sdb) have this feature. It IS doable. If > there are "other issues to consider" that is your job. We just want > the feature. We don't really care what it takes. I'm sure we're all waiting to see YOUR compiler/debugger product, Frank. /alastair/
awd@dbase.UUCP (Alastair Dallas) (09/27/89)
In article <11950@polya.Stanford.EDU>, kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: > In article <254@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: > > >I guess our only continuing disagreement, then, is where to put a global- > >context debugger on the priority list. It seems like a lot of pain for > >only a little gain, to me, so I'd put it fairly low on the list. > > I guess you must never (or seldom) play with recursive functions, such as > ray tracers or equation solvers. It's nice to know how you got where you > are when the stack overflows. > > BTW: I can do this just fine with Jasik's Debugger and MPW. Function call traceback is already available in the THINK C debugger. If all you want is to 'see how you got there' you can do that now. /alastair/
fjo@cbnewsc.ATT.COM (frank.j.owen) (09/27/89)
From article <256@dbase.UUCP>, by awd@dbase.UUCP (Alastair Dallas): > In article <3425@cbnewsc.ATT.COM>, fjo@cbnewsc.ATT.COM (frank.j.owen) writes: >> I think that the feature described in the original posting is a >> useful and valid one. Other compiler/debuggers (I don't know of any in the Mac >> arena - perhaps the Aztec sdb) have this feature. It IS doable. If >> there are "other issues to consider" that is your job. We just want >> the feature. We don't really care what it takes. > > I'm sure we're all waiting to see YOUR compiler/debugger product, Frank. > > /alastair/ I guess what alastair is saying here is if we know of a feature that would improve a product, our only option to getting that feature is to produce our own product. Interesting. Is this the general sentiment of others on the net? I would like to reiterate (and others on the net have also pointed this out) that this is NOT an unusual feature for a debugger to have. I have used debuggers (on other platforms) that have this feature and it is VERY useful. I would also like to say that I think the THINK product is generally a pretty good one. I just think that adding this feature to the debugger would make it more useable (i.e. better), that's all. When I say it is "doable" I'm NOT saying "I could write a compiler/debugger that could do this", what I'm saying is that OTHER compiler/debugger vendors HAVE done this, and I imagine that the talented people at THINK could probably do it, too. -- Frank Owen 312-982-2182 AT&T Bell Laboratories 5555 Touhy Ave., Skokie, IL 60077 PATH: ...!att!ihc!fjo
allbery@NCoast.ORG (Brandon S. Allbery) (09/29/89)
As quoted from <6238@pt.cs.cmu.edu> by pane@cat.cmu.edu (John Pane): +--------------- | In article <244@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: | >In article <85031@pyramid.pyramid.com>, bjb@pyramid.pyramid.com (Bruce Beare) writes: | >> The think C 4.0 debugger is not able to show stack variables for | >> functions that are 1 or more calling frames "up" the stack. | >> | >Does the word 'scope' ring a bell here? K&R, 1st Ed., p. 76: | >"The scope of a name is the part of the program over which the name is... | | This has nothing to do with rules of scope. When a program is running, the | state of the program includes variables that are in all of the active call | stack frames. It is perfectly reasonable to expect a debugger to allow the | programmer to inspect these values, and in fact most debuggers do. +--------------- Indeed. If function x() calls function y() and I have a breakpoint in y() so I can inspect variables, function x() is still active. I should be able to see its local variables and its arguments. Heck, even System V sdb, an arguably broken debugger, does this. Not that I have Think C, just a comment about debuggers, ++Brandon (P.S. Quick followup to my past posting on development systems: I just bought, used, MPW 2.02 + MPW Pascal. It'll do, I think. Anyone want to tell me otherwise so I'll know how much trouble I'm in?) -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp, 161-7070 BALLBERY (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie) Is that enough addresses for you? no? then: allbery@uunet.UU.NET (c.s.misc)
allbery@NCoast.ORG (Brandon S. Allbery) (09/29/89)
As quoted from <2693@husc6.harvard.edu> by siegel@endor.harvard.edu (Rich Siegel): +--------------- | Furthermore, it's currently impossible to find variables in frames | other than the current activation. Why? Because if the variable is allocated | in a register, it's been saved *somewhere* on the stack by a MOVEM instruction. | Currently, the compiler does not retain the information as to where the | saved registers are, or what they are, and there's no heuristic that the | debugger can apply in order to find the saved registers. Non-register +--------------- Huh? All it would take is a reasonably standard function-entry procedure: every function starts with LINK, MOVE.M, and ADD/ADDQ/LEA in a particular order (what order doesn't matter that much for this purpose, only that the same order must be used in all functions; of course, the interaction between them mandates some order from the processor's standpoint, but I forget at the moment what it is), all optional. The debugger can then peek at the beginning of the function's code to see how to disentangle the stack. UNIX debuggers do this regularly. Or am I missing something? (I doubt that UNIX-vs.-MacOS is a relevant distinction, since ultimately what we're talking about is standard 68000 function entry sequences and the OS could care less about them.) (No, I'm not needling you or anything like that; after nursemaiding old ncoast for eight years, I like to think I've learned something about the care and feeding of a 68000 at the assembly-language level... and here you're suggesting to me that it doesn't work that way on a Mac, just after I finally buy a development system. I'm beginning to fear that I'm going to have to start all over again despite my past experience....) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp, 161-7070 BALLBERY (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie) Is that enough addresses for you? no? then: allbery@uunet.UU.NET (c.s.misc)
allbery@NCoast.ORG (Brandon S. Allbery) (09/29/89)
As quoted from <254@dbase.UUCP> by awd@dbase.UUCP (Alastair Dallas): +--------------- | to show me the value of variables which are in context. If the program can't | see a variable in a particular context, I don't expect that the debugger | can, either. +--------------- Alastair, have you ever used Unix sdb or dbx (depending on your Unix's race ;-) ? Both have this capability, and it is invaluable. It's just not that difficult to provide, assuming the compiler outputs enough debugging information in the symbol table or etc. * t foo(bar=1, baz=2) [bar.c:74] bar(baz=3) [main.c:12] * bar:x/ 12 * _ I do this all the time; if you need to know, for example, *why* foo() got the arguments it did (or got called at all), you need to be able to examine the state of the calling function. That information is present on the stack, and as long as your debugger can follow return addresses to find function stack frames and it can understand stack frames at all -- the first is basic to a debugger, the second requires information from the compiler as to what got put into the stack frame, possibly along with some peeking at the function preamble -- it can find and display, and even modify, these variables. Even register variables if the compiler is nice enough to state in the symbol table that bar:x was assigned to, say, D4. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp, 161-7070 BALLBERY (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie) Is that enough addresses for you? no? then: allbery@uunet.UU.NET (c.s.misc)
awd@dbase.UUCP (Alastair Dallas) (10/02/89)
I'm taking all kinds of heat from this group for flaming the first guy who posted that the THINK C debugger should display (and modify) the automatic variables of caller's stack frames. I was jerk--I thought the fellow that made this request didn't understand scope of reference. One peculiar phenomenon has been private e-hatemail. When you post to the net that this or that idea is stupid, let's face it, you're trying to look smart to your peers. Second, you're educating people, but my point is that it's only human to criticize the ideas of others in public. In private, one-on-one email, however, I don't understand the desire for ad hominem attacks. "Jane, you ignorant slut" is fine on network t.v., but what's the point when you're mailing directly to Jane? Now that I understand that most if not all of the people who want this feature in the THINK C debugger do understand the concepts involved, I'm satisfied that we have a difference of opinion, not of fact. I stand behind my statement that this feature is not high on my personal wish list. This mail follows up a posting by a well-meaning fellow who describes 'sdb' and 'dbx'. I use dbx at work, and I've played with a windowing version on a Sun--it's very nice, and, yes, I'm aware that dbx has the feature under debate. It would be wonderful if THINK C could be everything to everyone; I'd like a world without tradeoffs. All I am adding to this debate is my personal opinion that I'd sooner see some of the features of cfront (c++) before I'd have Kahl et al implement dbx on a Mac Plus, ok? Flame on me all you want in public, but please don't track me down where I live. Thank you. /alastair/
bjb@pyramid.pyramid.com (Bruce Beare) (10/03/89)
In article <267@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: > >I'm taking all kinds of heat from this group for flaming the first >guy who posted that the THINK C debugger should display (and modify) >the automatic variables of caller's stack frames. I was jerk--I thought >the fellow that made this request didn't understand scope of reference. > >One peculiar phenomenon has been private e-hatemail. When you post to >the net that this or that idea is stupid, let's face it, you're trying >to look smart to your peers. Second, you're educating people, but my Alastair, Here you go again... It seems to me that you have a bad habit of mixing fact, opinion and emotion together in public postings. My reading of this last posting implies that I am one of those people that are trying to look smart to their peers. I believe that in my original posting in this thread I made my purpose quite clear. I want to insure that Think gets the message loud and clear - improve the debugger. A word of advice... think before you type. Bruce
jimc@iscuva.ISCS.COM (Jim Cathey) (10/03/89)
In article <3424@cbnewsc.ATT.COM> fjo@cbnewsc.ATT.COM (frank.j.owen) writes: >Many debuggers allow you to do this. It is a VERY nice feature. However, at least sdb (in Unix-land) _requires_ you to throw a compiler switch that in effect turns off all optimizations in order for the code generated to be regular enough for the debugger to pick apart. You then have to recompile anything you want to be able to look at or set breakpoints in, or trace stack frames through. Not very elegant, and the code you're debugging ends up very different than the code that had the problem (unless you always use the grunge switch). Unfortunately, because things moved around when you threw the switch a common class of bugs (mashed pointers) is usually very hard to find as something different (and usually less visible) is being bashed. I certainly wouldn't want the job of finding variables in stack frames far up the stack, especially when they were put into registers who are now in a different place on the stack. It could probably be done, especially if a comprehensive map file were created by the compiler, but how long are you willing to wait for it? Do you want it to hold up the release? A related problem is the size of the output file when the grunge switch is on. We have a 350K object file whose file size is over 1MB just because of all the symbol and stack frame offset crap in it. Of course, like Mom and apple pie I would sure _like_ the smarter debugger. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc (jimc@iscuva.iscs.com) ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
lim@iris.ucdavis.edu (Lloyd Lim) (10/03/89)
In article <86232@pyramid.pyramid.com> bjb@pyramid.pyramid.com (Bruce Beare) writes: >In article <267@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: >> >>I'm taking all kinds of heat from this group for flaming the first >>guy who posted that the THINK C debugger should display (and modify) >>the automatic variables of caller's stack frames. I was jerk--I thought >>the fellow that made this request didn't understand scope of reference. >> >>One peculiar phenomenon has been private e-hatemail. When you post to >>the net that this or that idea is stupid, let's face it, you're trying >>to look smart to your peers. Second, you're educating people, but my > > Here you go again... It seems to me that you have a bad habit of mixing >fact, opinion and emotion together in public postings. My reading of this >last posting implies that I am one of those people that are trying to look >smart to their peers. Please, let's get off of this subject. Alastair has made his point clear and even admitted he might have been a jerk. Bruce you've made your point too. When Alastair talks about saying an idea is stupid, it seems like he might be referring to himself also, so let's not take it so personally. I've gotten both of your points of view long ago. I understand the phenomena of network delay but I hope everyone will get off this subject. +++ Lloyd Lim Internet: lim@iris.ucdavis.edu (128.120.57.20) Compuserve: 72647,660 US Mail: 146 Lysle Leach Hall, U.C. Davis, Davis, CA 95616 . . . . . . . . . . .
mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) (10/03/89)
Very seldom does a string of articles annoy me, but this one certainly does.
Please, no more. Squabble elsewhere.
Everyone is entitled to his or her own opinion. (And leave the poor guy
alone.)
-Michael
--
Michael Niehaus UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!mithomas
Apple Student Rep ARPA: mithomas@bsu-cs.bsu.edu
Ball State University AppleLink: ST0374 (from UUCP: st0374@applelink.apple.com)lippin@spam.berkeley.edu (The Apathist) (10/04/89)
Recently jimc@iscuva.ISCS.COM (Jim Cathey) wrote: >However, at least sdb (in Unix-land) _requires_ you to throw a >compiler switch that in effect turns off all optimizations in order >for the code generated to be regular enough for the debugger to pick >apart. You then have to recompile anything you want to be able to >look at or set breakpoints in, or trace stack frames through. Not >very elegant, and the code you're debugging ends up very different >than the code that had the problem (unless you always use the grunge >switch). Similarly, in LSC there's the "gray diamond" switch to be thrown. You can't debug a file unless it was compiled with switch on, it turns off all optimization (as there isn't any to speak of to begin with), and it increases the size of your project file. So what's the difference? --Tom Lippincott lippin@math.berkeley.edu "This view derives partly from what is known as common sense, whose virtue, uniquely among virtues, is that everyone has it." --Tom Stoppard, _Jumpers_