https://sourceware.org/bugzilla/show_bug.cgi?id=27573
--- Comment #8 from Frank Ch. Eigler ---
OK - once gdb fixes that shortcoming, the .cache should contain
both executables and debuginfo, and then zip-packing up the
cache should fulfill this use case with existing elfutils code.
--
You are r
https://sourceware.org/bugzilla/show_bug.cgi?id=27573
Martin Liska changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://sourceware.org/bugzilla/show_bug.cgi?id=27573
--- Comment #6 from Frank Ch. Eigler ---
> To be honest, gdb should be able to load all these with libdebuginfod-client
> library.
It can - as long as $DEBUGINFOD_URLS is set to something, anything, the client
library will gladly check out t
https://sourceware.org/bugzilla/show_bug.cgi?id=27573
--- Comment #5 from Martin Liska ---
> If the use case is letting a gdb user without debuginfod connectivity of her
> own access a cache of debug content ... perhaps transmit a tarball of
> $HOME/.cache/debuginfod along with the core dump?
Th
https://sourceware.org/bugzilla/show_bug.cgi?id=27573
--- Comment #4 from Frank Ch. Eigler ---
see also perf-archive(1)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27573
--- Comment #3 from Frank Ch. Eigler ---
A single coredump executable that contains all the solib bits + all the
debuginfo for all the solibs ... is that even possible in principle?
If the use case is letting a gdb user without debuginfod con
https://sourceware.org/bugzilla/show_bug.cgi?id=27573
--- Comment #2 from Martin Liska ---
(In reply to Mark Wielaard from comment #1)
> I assume this would be some kind of "pack" command? Which would pack all
> relevant files, executables and debuginfo together into one directory?
Exactly.
>
https://sourceware.org/bugzilla/show_bug.cgi?id=27573
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org
--- Comment #1
