当已在“常规"调试器语句中停止时,如何进入eval('debugger')模式? [英] how do I go into eval('debugger') mode when already stopped at 'regular' debugger statement?

查看:370
本文介绍了当已在“常规"调试器语句中停止时,如何进入eval('debugger')模式?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我最近开始用eval('debugger')语句换出所有debugger语句.原因是在普通版本中,并非所有的实际上/理论上"的可见变量都是实际地"可见的.发生这种情况是由于优化(请参见早期的SO问题).

I recently started to swap out all my debugger statements with eval('debugger') statements. The reason is that with the plain version, not all "factually/theoretically" visible variables are "practically" visible. This happens because of optimization (see earlier SO question).

使用此技巧,问题就像"90%已解决"一样-存在一些缺点.除了更长的源代码之外,这些还有:

With this trick, the problem is like "90% solved" - there are some drawbacks. Apart from longer source code, those are:

  • 当涉及到第三方库时,这是不可行的,甚至也无法在其中进行debugger-> eval('debugger')转换.
  • 当我宁愿在调试器本身中设置一个断点而不是更改代码时,那是无法完成的?或者可以吗?
  • 当我已经停止在普通" debugger语句(在第三方代码中,或者我忘记了的地方)时,无法切换到所需的模式-一定要在控制台上键入eval('debugger')没有帮助.如果需要功能,则必须更改调试器语句,然后再次运行代码,这可能是很多工作
  • 当我在eval('debugger')语句处停止但使用调试器的逐步/进入/退出"功能时,我失去了特殊的状态".
  • When third party libraries are involved, it is not feasible, maybe not even possible to have the debugger -> eval('debugger') transformation done there also.
  • When I would rather set a break point in the debugger itself, instead of changing the code, that cannot be done - or can it?
  • When I'm already stopped at a "normal" debugger statement (in third party code, or where I forgot one), there is no way to switch to the desired mode - certainly typing eval('debugger') on the console doesn't help. If I want the functionality, I have to change the debugger statement, and run the code again, which might be a whole lot of work
  • When I stopped at an eval('debugger') statement, but then use the debugger 'step over/into/out' functionality, I 'lost my special status'.

我该如何解决?有没有办法告诉v8通过eval('debugger')解释所有调试器语句?有什么技巧可以进入另一种模式"-好像eval('debugger')语句将在您停止的debugger语句之后神奇地显示为下一条语句? chrome可执行文件的命令行选项有帮助吗? Firefox中可能有办法吗?

How can I work around this? Is there a way to tell v8 to interpret all debugger statements by eval('debugger')? Is there a trick with which you can 'go into the other mode' - as if the eval('debugger') statement would magically appear as the next statement after the debugger statement where you're stopped? Do command line options to the chrome executable help? Maybe there is a way in firefox?

我在 公告

我接下来要做的是编写一个小编译器以供在节点Web服务器中使用. Transpiler将在所有位置插入eval('')语句(默认情况下,在每个函数的开头/主体处插入一次,如果在查询字符串中指定,则在其中插入更多或更少的语句.)然后,我可以在eval语句所在的位置设置断点是,进入",然后我得到了我想要的.然后,我将回答我自己的问题.

What I'm going to do next is write a little transpiler for usage within node webserver. The transpiler will insert eval('') statements all over the place (by default once at the beginning/body of every function, and more or fewer of them if so specified in the query string.) Then I can set a breakpoint where the eval statement is, do "step into" and then I got what I want. Then I'm going to answer my own question.

除非当然,否则有人会击败我.那将是最令人高兴的,因为我还有其他事情要做.

Unless of course, someone will beat me to it. That would be most delightful, as I do have other things to do.

推荐答案

V8开发人员在此处.

V8 developer here.

是否可以通过eval('debugger')告诉v8解释所有调试器语句?

Is there a way to tell v8 to interpret all debugger statements by eval('debugger')?

目前尚无办法将debugger语句或断点视为eval("debugger"),但是添加执行此操作的标志可能是可行的.您可以在 crbug.com/v8/new 提交功能请求"错误,并要求标记强制上下文分配所有变量以进行调试.

There is currently no way to treat debugger statements or breakpoints as eval("debugger"), but it might be feasible to add a flag that does this. You can file a "feature request" bug at crbug.com/v8/new and ask for a flag that forcibly context-allocates all variables for debugging purposes.

(注释1:在这里起作用的是eval部分.只要在函数中的某个位置具有eval,就可以编写eval(""); debugger;debugger; other_code(); eval("");代替eval('debugger').)

(Side note 1: It's the eval part that has an effect here. Instead of eval('debugger') you could write eval(""); debugger; or debugger; other_code(); eval("");, so long as you have eval somewhere in the function.)

(注2:这里的紧张之处在于,一方面,当程序在调试时与未调试时的行为相同,这是Good™的问题;否则可能存在问题仅在调试或生产模式中出现不可调试的故障时才会显示;另一方面,有时为了使调试成为可能,显式地需要某些偏差.我不确定这是在哪一边.分配所有变量将降低性能并增加内存消耗,因此,如果/当这种模式可用时,您可能必须(或希望)在开发工作中来回切换;这尤其意味着这不能简单地是打开DevTools时的默认设置.)

(Side note 2: the tension here is that on the one hand, it's Good™ when the behavior of a program when it is being debugged is the same as when it is not being debugged -- otherwise there might be issues that only show up when debugging, or un-debuggable failures in production mode. On the other hand, sometimes certain deviations are explicitly necessary in order to make debugging possible. I'm not sure on which side of the line this one falls. Context-allocating all variables will reduce performance and increase memory consumption, so if/when such a mode becomes available, you will probably have to (or want to) switch back and forth during your development work; which in particular means that this couldn't simply be the default when DevTools are open.)

是否有一个技巧可以进入另一种模式"-好像eval('debugger')语句将神奇地显示为在您停止的debugger语句之后的下一条语句?

Is there a trick with which you can 'go into the other mode' - as if the eval('debugger') statement would magically appear as the next statement after the debugger statement where you're stopped?

不,不可能.它不是模式"或特殊状态",而是在首先解析/编译外部函数(包含要在内部函数中看到的变量的函数)时必须做出的决定).一旦时间过去,更改任何内容就为时已晚(非上下文分配的变量就消失了),唯一的选择就是重新加载.

No, and there can't be. It's not a "mode" or "special status", it's a decision that has to be made when first parsing/compiling the outer function (the one that contained the variable you want to see within an inner function). Once that time has passed, it's too late to change anything (non-context-allocated variables are just gone), and the only option is to reload.

[根据评论进行 为了澄清我的意思是不是模式,而是决定":从范围链的角度来看,情况基本上与以下情况相同:

[EDIT in response to comments: To clarify what I mean by "not a mode, but a decision": from the scope chain's point of view, the situation is essentially the same as:

var inner;
function outer() {
  var foo = "foo";
  var bar = "bar";
  inner = function() {
    console.log(bar);
    debugger;
  }
  // "inner();" here is moved below
}
outer();
inner();

在调用inner()时,foo仍然像bar一样存在(如果它是上下文分配的,因为在outer的编译时V8确定inner将需要它),或者(如果V8确定它在outer中是本地的,并且没有其他人需要它).如果inner包含eval,则可能需要 all 个外部作用域变量. -编辑结束]

at the point when inner() is called, foo is either still there like bar (if it's context-allocated because at compile time of outer V8 determined that inner will need it), or gone (if V8 determined that it's local to outer and nobody else will need it). If inner contains eval, then it might need all outer-scope variables. --end of EDIT]

这是由于优化而发生的

This happens because of optimization

好...由于 优化,也就是说,要聪明地在堆栈上还是在上下文对象"中分配变量.这与通常所谓的函数优化"完全无关,即通过优化编译器运行它们.这就是为什么在另一期中讨论的%NeverOptimizeFunction黑客无效的原因-这是一个不相关的机制.

Well... because of an optimization, namely being smart about whether to allocate variables on the stack or in the "context object". This is completely unrelated to what is typically referred to as "optimization of a function", i.e. running them through the optimizing compiler. That's why the %NeverOptimizeFunction hack discussed in the other issue had no effect -- it's an unrelated mechanism.

这篇关于当已在“常规"调试器语句中停止时,如何进入eval('debugger')模式?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆