From:  Brian Slesinsky <skybrian@google.com>
Date:  18 Mar 2014 08:46:44 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.js-sourcemap
Subject:  

Re: better document the "names" field in Source Maps

NNTP-Posting-Host:  63.245.216.66

Okay, then what should a language-independent debugger do with the names
field, since it doesn't know anything about the source language? Do we want
the name to appear in stack traces as a function name? If so, that
constrains what compilers should put there, at least for those JavaScript
ranges that cover executable code where a breakpoint could be set.

A related issue is how a debugger decides whether a breakpoint can be set
at a particular source line. I believe in Chrome, any source line that maps
to a JavaScript range is assumed to be a valid place to put a breakpoint.
If the compiler doesn't want debuggers to allow a source-level breakpoint
there, the only influence the compiler has is to not map that range.

GWT currently doesn't do a great job of this (breakpoints can be set in
weird places and can be jump around). We could clean things up for Chrome
but other browsers should work similarly. So it seems like the spec could
be a good place to say how to communicate effectively with debuggers.

- Brian



On Mon, Mar 17, 2014 at 5:11 PM, John Lenz  wrote:

> Yeah, it isn't clear and was left in primarily because it have any cost
> associated with it. But yes, the intent was to provide to link to the
> original names used for a variable, with the Closure Compiler's various
> form of variable and property name forking and joining (when fully
> optimized) there is no way to use a simply map of names, so you need to
> provide it at the place of reference.
>
> But no one has really taken advantage of this for a while as Joey points
> out .
>
>
> On Mon, Mar 17, 2014 at 4:50 PM, Joey Schorr  wrote:
>
>> The intention was to both deobfuscate stack traces and provide a way for
>> de-minimization of source code if the mapping was semi-direct. The old
>> Closure Inspector (https://code.google.com/p/closure-inspector/) would
>> actually use the names to remap the source code view inline, but this
>> obviously only applied to the Closure case where the input language was
>> also (basically) JavaScript.
>>
>>
>> On Mon, Mar 17, 2014 at 7:41 PM, Brian Slesinsky wrote:
>>
>>> (Sending this to the list since I can't comment directly on the
>>> document.)
>>>
>>> Re:
>>>
>>> https://docs.google.com/a/google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit#
>>>
>>> A comment on this line:
>>>   Line 7: A list of symbol names used by the “mappings” entry.
>>>
>>> I think the spec should explain a bit more about how this is typically
>>> used. Despite doing a fair amount of work with sourcemaps, I was unclear
>>> on
>>> this until recently.
>>>
>>> As far as I know no debugger uses the "names" field, but the intention is
>>> to deobfuscate stack traces. That is, when a JavaScript exception occurs
>>> or
>>> a debugger stops at a breakpoint, we can treat the stack trace as a list
>>> of
>>> positions in JavaScript files. For each position, the "name" is the
>>> deobfuscated function name that should appear in the stack trace. (Or
>>> more
>>> generally, it is whatever string would most usefully appear in the
>>> function
>>> name position when displaying a stack frame in the debugger.)
>>>
>>> - Brian
>>> _______________________________________________
>>> dev-js-sourcemap mailing list
>>> dev-js-sourcemap@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-js-sourcemap
>>>
>>
>>
>