superfuncIts nice that GDB auto fetches debug sources these days
but I wish they didn't update so often
Ritesh Oedayrajsingh Varma@superfunc it does? how? from
where? or do you mean it installs the source packages via the package manager?
where? or do you mean it installs the source packages via the package manager?
Josh Simmons@rovarma @superfunc from debuginfod, it serves sauce as well as symbols.
@rovarma @superfunc When you launch gdb it says "do you want to enable debuginfod" and you say "y", and then it downloads the debug info for whatever modules get loaded. Then you hit a breakpoint, and jump to a frame and it does this...
@dotstdy @superfunc ah, ok, yeah — we have support for all of that in Superluminal too, but Ubuntu doesn’t serve sources from their debuginfod server for reasons I don’t know, so I haven’t seen the source part working yet. Guessing you guys are on another distro that does serve them?
@rovarma @superfunc I'm on arch, which does. I think fedora does as well since that's where most of the upstream work comes from.
@rovarma @superfunc Ubuntu might just be shipping ancient versions of gdb et at as well.
@dotstdy @superfunc thanks, yeah, I figured. It’s not related to gdb version; I’ve implemented this in Superluminal according to the debuginfod spec and we’re not able to retrieve source files either, but retrieving symbols works fine. I read somewhere during my research that Ubuntu doesn’t serve sources. I can’t find that reference anymore, but it matches my experience.
@dotstdy @superfunc honestly I think the source endpoint of debuginfod is the wrong approach for this anyway. It basically forces the distro to host the source for all packages they have, instead of just like pointing to a VCS repo (git etc) like a sane source indexing solution would. I’m considering writing a source indexing solution like that myself that would initially only work for Superluminal, but might (hopefully) get picked up by other tooling such as gdb…
Ted Mielczarek@rovarma @dotstdy @superfunc Microsoft's source server implementation lets you do this in a sensible way. If you debug a Firefox release build on Windows it will fetch the source from VCS over https. (I did a bunch of the work in the Firefox build to enable that.)
@tedmielczarek @dotstdy @superfunc Yep — that’s what I was referring to with “sane source indexing solution” :-)
It does have some issues with trust as you’re basically executing random commands that happen to be embedded in the PDB, but on the whole it is a much better approach. I feel like you could get something similar working on Linux by embedding similar information in a debug section, but perhaps with “well known“ types of VCS’s supported to avoid the implied RCE in MS’s implementation.
Markus Stange@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
@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.
@mstange @rovarma @tedmielczarek @superfunc paths in general are just an absolute nightmare in dwarf et al :'( i spent a bunch of time trying to get source paths to resolve properly across the WSL boundary and let me tell you after that experience i'm thinking everyone should just copy the entire source code tree into the pdb...
@mstange @rovarma @tedmielczarek @superfunc just jam the entire input into the build in a content addressed store, use hashes to find source files, and then have the paths as a fallback / informational rather than the canonical url...
@mstange @tedmielczarek @dotstdy @superfunc Interesting! I was thinking along similar lines, though I settled on a .debug_sourcelink section, to mirror the existing .gnu_debuglink.
I can write something up about it, but in short it would basically be the source indexing idea, where you map a particular root path to a VCS path. The difference from source indexing is that you wouldn’t have to index each individual file; I never saw the point of that.
@mstange @tedmielczarek @dotstdy @superfunc There’d be some way to map a particular root path to a “VCS provider”, some list of well known VCS providers, and support for mapping multiple root paths to different providers.
I was initially planning on adding support for this to Superluminal, and to ship a (permissively licensed) library to do the indexing & retrieval to help adoption in other tools.
@mstange @tedmielczarek @dotstdy @superfunc Even if this might not be that useful to package maintainers as Josh mentioned, I think it would still be very helpful to ISVs.
Regarding paths in DWARF: the way I’m thinking about it, this would be orthogonal. You have “some” way to retrieve the original source file path from DWARF as you usually would, and then a way to map that path to a VCS provider using the section and retrieve it. The library would only be responsible for the second part.
@mstange @tedmielczarek @dotstdy @superfunc Would be happy to chat about this to come up with a final design for it; I think this is a pretty big hole in debugging/profiling on Linux, but we can fix it :-)
@rovarma @mstange @dotstdy @superfunc humorously, that's basically what the Python script that builds the source index for Firefox binaries does. It then uses that to map each source file to the proper location.