4 ms·
That is not true, the fifth field of the mapping is the original name of the variable.
by cromwellian 13y ago
That is not true, the fifth field of the mapping is the original name of the variable.
- kevingadd 13y agoI just reread the spec and no mention of variables exists in it. That was definitely not added as a feature when I read the spec initially. Can you cite the relevant part of the spec and demonstrate how it is used? P.S. Variables live in scopes, so attaching variable information to line mappings is pretty gross... I suppose if it works it works, so better than nothing.
- cromwellian 13y agohttps://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiO... The 'names' field is a list of all original symbols in the program. Each mapping is 1, 4 or 5 fields long. If 5 fields long, the 5th field is an index into this names field, e.g. Or see a more readable description on html5rocks http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ http://www.html5rocks.com/en/tutorials/developertools/source...
- kevingadd 13y agoThank you. Even now, rereading the spec and looking at the part you identified, I can barely tell it does what it does. That html5rocks overview is much better. It'd be great if they revised the spec to not use such opaque terminology, and directly describe what the 'names' list is used for. The only reference I can find that explains this is 'If present, the zero-based index into the “names” list associated with this segment', which I only understand how that you said what it means. Since one of your other comments made it unclear: Does this apply to all variables, or only global variables?
- skybrian 13y agoI haven't seen the names field actually used by a debugger, so it's somewhat theoretical.
- cromwellian 13y agoI don't think you've seen them in Chrome Dev Tools with GWT because I don't believe we are generating the source maps properly. IIRC, I asked about this before and was told Dev Tools does support deobfuscating globals as far as the stack frame is concerned. The fact that we are still seeing obfuscated function names on the call stack I think is our bug. Edit: I take that back. I just looked at the Blink source code, as far as I can tell, it throws away the name index. Therefore, Chrome Dev Tools won't deobfuscate symbols, but Google server-side JS deobfuscation framework will, which is a pitty. I guess it is time for a Chrome Dev Tools patch. :)