From: Rocky Bernstein Date: 2011-10-26T21:00:05+09:00 Subject: [ruby-core:40411] Re: 2.0 feature questionnaire --f46d041703456707c304b0326463 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 26, 2011 at 3:39 AM, Charles Oliver Nutter wrote: > > As you probably know, I'm still of the opinion that debug time and > runtime have completely different characteristics. Yes, I thought it improbable that you would believe otherwise. Expecting that > debug-time binding access (frame access, local variable modification, > etc) should be available at normal runtime is unreasonable... I wouldn't put it so strongly, especially as I can think of many implementations of dynamic languages, including Ruby implementations where this is the case and where it is unlikely for those implementations to change drastically. it's not > possible to do this without killing many, many optimizations. I understand your point and don't disagree. The extent to which optimization is important and how important versus allowing run-time dynamicism including environment access (which is typically used by debuggers in systems that provide it) I am unwilling to take a stand or pass judgement on. You and > I discussed that those optimizations could still be active and > debuggers would just lose functionality...but I'm not sure I see that > being useful. I think I take a minority opinion here. Debugging for me is about transparency. Here, that means giving the programmer an understanding of what the running program is doing -- whatever that may be. If the translation system has heavily modified the source code, so be it. When there's something horribly wrong that a programmer needs to be involved, offering what is there is better than saying, sorry you are out of luck. For decades programmers have debugged optimized C code with gdb. Is it the preferred way to go? No. Given the choice of starting over but first recompiling without optimization and running again with debugging, just about always a C programmer will do that. But in some situations you can't. I think there would be a number of C programmers, myself included, who would be disappointed if you said you can *only* debug C code that has no optimization. If JRuby eliminated all local variables for a given > method and the debugger was unable to see them, what use is the local > variable feature of the debugger Right, it's not useful in that particular context. What I'd request though is that the transformation system kept some sort of information indicating that local variables were eliminated. It could be done on a very coarse level, such as recording that you are in optimized code or recording the compilation options. Or a fine level such as recording which locals were eliminated. In the patches to MRI/YARV 1.9.2, one thing I changed is the ability to not throw out the compile flags that are normally stored during compilation; this is the default if we think debugging is on which is determined if the __SCRIPT_LINES__ hash is set. In the gcc case, sometimes one will ask about local variables and if they happen to be in a register you may get the wrong answer. It's not great, but personally I've gotten used to it. And I prefer that to the "sorry out of luck" answer. Or a solution where a debugger that *never* allows me ask about local variables. Again, I am probably in the minority, but I sometimes may disassemble code in gdb which usually clues me into whether I can expect the variable to be stored in the place gdb is probably looking at. So again, I probably am the only one who uses this, but for the trepanning debuggers as well as for the python debuggers before it, have a command to show bytecode disassembly. I'm still of the opinion that > debugging will almost always be most useful in a mode that limits > optimizations normally invisible to the user, so we're talking about a > completely different mode of execution where full-system binding > access may be just fine. > I don't disagree. And this works. Obviously, because that's how debugging in more static languages invariably works. It could also be that way for more dynamic languages as well. But it's all in the details. And that's why I take interest here. Let's take for example the recent proposal of adding Dtrace enhancements for debugging in MRI 2.0. I'm not totally sure what that means (which is my bad), but I suspect that whatever this does it has nothing to change the way variables are accessing/modified in a debugger. So before closing, I will reiterate an observation I've only slowly noticed: the state of debuggers has a tendency of getting worse. Just as you would like to hold the line or improve what can be optimized in a language system, I would like to hold the line or improve debugging, tracing, profiling and debuggers in such systems. > > In any case, this is a bit off topic. > Yep. And with this too long post I think I have overstayed my welcome. In the back of my mind I think most of what I want is relevant to or of interest to very few. So if this falls on deaf ears, like the ability to ask about local variables: so be it. > - Charlie > > --f46d041703456707c304b0326463 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 26, 2011 at 3:39 AM, Charles Oliver Nutter &l= t;headius@headius.com>= wrote:

As you probably know, I'm still of the opinion that debug time an= d
runtime have completely different characteristics.

Yes, I thought it improbable that you would believe otherwise.=A0<= /div>

Expecting that
debug-time binding access (frame access, local variable modification,
etc) should be available at normal runtime is unreasonable...
<= div>
I wouldn't put it so strongly, especially as I can t= hink of many implementations of dynamic languages, including Ruby implement= ations where this is the case and where it is unlikely for those implementa= tions to change drastically.

it's not
possible to do this without killing many, many optimizations.
=

I understand your point and don't disagree. =A0The = extent to which optimization is important and how important versus allowing= run-time dynamicism including environment access (which is typically used = by debuggers in systems that provide it) I am unwilling to take a stand or = pass judgement on.

You and
I discussed that those optimizations could still be active and
debuggers would just lose functionality...but I'm not sure I see that being useful.

I think I take a minority op= inion here. Debugging for me is about transparency. Here, that means giving= the programmer an understanding of what the running program is doing -- wh= atever that may be. If the translation system has heavily modified the sour= ce code, so be it. When there's something horribly wrong that a program= mer needs to be involved, offering what is there is better than saying, sor= ry you are out of luck.=A0

For decades programmers have debugged optimized C code = with gdb. Is it the preferred way to go? No. Given the choice of starting o= ver but first recompiling without optimization and running again with debug= ging, just about always a C programmer will do that. But in some situations= you can't. =A0I think there would be a number of C programmers, myself= included, who would be disappointed if you said you can *only* debug C cod= e that has no optimization.=A0

If JRuby eliminated all loca= l variables for a given
method and the debugger was unable to see them, what use is the local
variable feature of the debugger

Right, it&= #39;s not useful in that particular context. What I'd request =A0though= is that the transformation system kept some sort of information indicating= that local variables were eliminated. It could be done on a very coarse le= vel, such as recording that you are in optimized code or recording the comp= ilation options. Or a fine level such as recording which locals were elimin= ated.=A0

In the patches to MRI/YARV 1.9.2, one thing I changed i= s the ability to not throw out the compile flags that are normally stored d= uring compilation; this is the default if we think debugging is on which is= determined if the __SCRIPT_LINES__ hash is set.

In the gcc case, sometimes one will ask about local var= iables and if they happen to be in a register you may get the wrong answer.= =A0It's not great, but personally I've gotten used to it. And I pre= fer that to the "sorry out of luck" answer. Or a solution where a= debugger that *never* allows me ask about local variables. =A0Again, I am = probably in the minority, but I sometimes may=A0disassemble=A0code in gdb w= hich usually clues me into whether I can expect the variable to be stored i= n the place gdb is probably looking at. =A0

So again, I probably am the only one who uses this, but= for the trepanning debuggers as well as for the python debuggers before it= , have a command to show bytecode disassembly.

=A0
I'm still of the opini= on that
debugging will almost always be most useful in a mode that limits
optimizations normally invisible to the user, so we're talking about a<= br> completely different mode of execution where full-system binding
access may be just fine.

I don't di= sagree. And this works. Obviously, because that's how debugging in more= static languages invariably works. It could also be that way for more dyna= mic languages as well. But it's all in the details. And that's why = I take interest here.=A0

Let's take for example the recent proposal of addin= g Dtrace enhancements for debugging in MRI 2.0. I'm not totally sure wh= at that means (which is my bad), but I suspect that whatever this does it h= as nothing to change the way variables are accessing/modified in a debugger= .=A0

So before closing, I will reiterate an observation I= 9;ve only slowly noticed: the state of debuggers has a tendency of getting = worse. Just as you would like to hold the=A0line=A0or improve what can be o= ptimized in a language system, I would like to hold the line or improve deb= ugging, tracing, profiling and debuggers in such systems.=A0
=A0

In any case, this is a bit off topic.
=A0
Ye= p. And with this too long post I think I have overstayed my welcome. In the= back of my mind I think most of what I want is relevant to or of interest = to very few. So if this falls on deaf ears, like the ability to ask about l= ocal variables: so be it.=A0


- Charlie


--f46d041703456707c304b0326463--