Hi Arjan, On Fri, 2020-02-07 at 06:47 -0800, Arjan van de Ven wrote: > On 2/7/2020 1:13 AM, Mark Wielaard wrote: > > On Wed, Feb 05, 2020 at 02:05:42PM -0800, Arjan van de Ven wrote: > > > On 2/5/2020 11:14 AM, Frank Ch. Eigler wrote: > > > > AIUI that works by using the "/usr/lib/debug/.build- > > > > id/HE/XCODE" as the > > > > key, i.e., the build-id as a file name. > > > > > > sure but it's not "/usr/bin/true" of which you might have > > > different versions over > > > the lifespan of a distro through its updates > > > > > > (e.g. you can connect gdb to a process that got updated on disk > > > later and still get the right answers) > > > > Do you also handle the core file use case? There you might not have > > the right /usr/bin/true version on disk. > > but the core file has the buildid in it (usually)....
Yes. I just simply don't know how the clr_debug_fuse.service handles that. I can see how it could handle that. But I don't know if it currently does. I assumed that the buildid.tar files on https://download.clearlinux.org/debuginfo/lib/.build-id/ would contain the ELF image corresponding to the build-id. Just like the buildid.debug.tar contains the separate .debug image. At least, that would be how I would handle it. But it seems those files contain symlinks. How do those symlinks get resolved? The use case here is a core file generated on an older or newer install. So you might not have the precise binary version installed on your local system. Does the clr_debug_fuse.service provide the binary ELF image corresponding to the buildid found in the core file? Or does it (currently) only provide the .debug file? Thanks, Mark
