contrasting elfutils debuginfod and clr-debug-info server

[Mark Wielaard]

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