Markus Stange
@mstange
- 166 Followers
- 305 Following
- 9 Posts
At Mozilla, working on Firefox performance and on the Firefox Profiler. he/him
@rovarma @tedmielczarek @dotstdy @superfunc Actually there's another annoying aspect of srcsrv: It has to list the full unmapped paths for all used source files. This is quite repetitive when all you want is to remap a prefix. And with DWARF debug info, file paths are specified in two pieces (directory + filename IIRC), and I'm not sure if it's fully unambiguous how to connect the two pieces to form the full path. IIRC there was something funky with relative paths.
@rovarma @tedmielczarek @dotstdy @superfunc I'd be super interested in following the conversation about this. I have considered making samply-symbols support a .debug_srcsrv section with the same format as in the pdb. I agree though that the code execution stuff is annoying; in samply I pattern match Chrome's use of it and only support URLs for everything else: https://github.com/mstange/samply/blob/b24354bcdba4236e0a05b7a067b3eeb43a606ce3/samply-symbols/src/windows.rs#L449
@Gankra @RAOF @fasterthanlime @dysfun Framepointer-based unwinding has the advantage that you don't need to know anything about which libraries are loaded and where to find their unwind info. So it's much easier to manage, in addition to the faster unwinding speed.
@Gankra @RAOF @fasterthanlime @dysfun The unwinding part of samply is done by framehop: https://github.com/mstange/framehop
The tricky part about using it from backtrace-rs would probably be the detection of when libraries are loaded into / unloaded from the process. Or in other words, the tricky part about caching unwind rules is knowing when to invalidate the cache. I don't know how libunwind does that part.
@jamey @brendangregg Interesting - why are you outputting unwinding dwarf for JIT if you also have framepointers in the jit code? Is it needed for GDB unwinding to work?
@gabrielesvelto @brendangregg Framepointers and inlining are two totally orthogonal issues though. Framepointers give you reliable and simple unwinding, and having them is super valuable regardless of whether you resolve inlining during symbolication.
@Gankra Ah I see, that makes sense.
Ok so if you just grab the dSYM bundle and the dwp file and upload those as extra artifacts, that should be all that’s needed. And don’t strip the Linux binary; it contains debug info which is not in the dwp.
A dSYM is quite similar to a pdb. It’s a self contained unit with all debug info. It is paired with its corresponding binary by virtue of having the same mach-O UUID. This UUID is written down in the files and is usually not spelled out in the filename.
@Gankra Ah nice, I'm curious to see your evaluation once you get a chance.
@Gankra Congrats on the release! Btw did you see my treatise on DWP? https://github.com/rust-lang/rust/issues/105991
Are dwp files the right choice for split-debuginfo=packed on Linux? · Issue #105991 · rust-lang/rust
@davidtwco @bjorn3 @philipc @Gankra @khuey Hi all, I was reading up on split dwarf and DWP files and came away rather confused. What is a situation in which using split dwarf + DWP is preferable ov...