4 ms·

JavaScript doesn't use DWARF. DevTools and production server systems do. If you think DWARF is better, write up a patch to Babel or Closure Compiler, and a devt

JavaScript doesn't use DWARF. DevTools and production server systems do. If you think DWARF is better, write up a patch to Babel or Closure Compiler, and a devtools extension. I think you'll problem find that DWARF doesn't really match the source-to-source profile case well, and in the end, you'll add so many extensions that what you end up with isn't DWARF at all. SourceMaps can be used to global names, but not locals. However, Closure Compiler has the ability to generate more elaborate maps that do allow reverse mapping. This is how Google services deobfuscate logs and stack traces sent back by heavily optimized clients.

the_mitsuhiko 9y ago
> However, Closure Compiler has the ability to generate more elaborate maps that do allow reverse mapping Is that an extension to source maps that Google came up with? Because from the current specification I do not see how this can be done without hacks. The way we're doing it is inverse token search from a starting position over the minified tokens until we find our minified function name followed by the keyword 'function'. And that approach is slow and not entirely correct.
- cromwellian 9y ago
  SourceMaps as specified are an interop format for devtools on the client side. On the server side, you can store a lot more information since it doesn't need to be transmitted to the client. Closure Compiler stores maps for all variables, all properties, all functions, all renamed strings, all idGenerators, etc. You can store these if you want. Google's servers store these maps and when user feedback or exceptions are logged, they are used to deobfuscate them. SourceMaps + functionMaps + propertyMaps + the others I mentioned as used to deobfuscate. This doesn't solve the problem of deobfuscating locals or heap objects. That needs an extension.
  - the_mitsuhiko 9y ago
    Sure. But what you describe is not possible with the documented sourcemap format. You can’t even map function names at the moment. It’s purely a token and token location mapping format.

the_mitsuhiko 9y ago

> However, Closure Compiler has the ability to generate more elaborate maps that do allow reverse mapping Is that an extension to source maps that Google came up with? Because from the current specification I do not see how this can be done without hacks. The way we're doing it is inverse token search from a starting position over the minified tokens until we find our minified function name followed by the keyword 'function'. And that approach is slow and not entirely correct.

cromwellian 9y ago
SourceMaps as specified are an interop format for devtools on the client side. On the server side, you can store a lot more information since it doesn't need to be transmitted to the client. Closure Compiler stores maps for all variables, all properties, all functions, all renamed strings, all idGenerators, etc. You can store these if you want. Google's servers store these maps and when user feedback or exceptions are logged, they are used to deobfuscate them. SourceMaps + functionMaps + propertyMaps + the others I mentioned as used to deobfuscate. This doesn't solve the problem of deobfuscating locals or heap objects. That needs an extension.
- the_mitsuhiko 9y ago
  Sure. But what you describe is not possible with the documented sourcemap format. You can’t even map function names at the moment. It’s purely a token and token location mapping format.