[Bug debuginfod/27571] New: debuginfod client cache should consist of 444 perm files
https://sourceware.org/bugzilla/show_bug.cgi?id=27571 Bug ID: 27571 Summary: debuginfod client cache should consist of 444 perm files Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- It would be undesirable to let files in the debuginfod cache be accidentally modified after download. We should chmod them 444 or equivalent after a download is completed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/27573] New: eu-unstrip: assemble debugable executable for a core file
https://sourceware.org/bugzilla/show_bug.cgi?id=27573 Bug ID: 27573 Summary: eu-unstrip: assemble debugable executable for a core file Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools Assignee: unassigned at sourceware dot org Reporter: mliska at suse dot cz CC: elfutils-devel at sourceware dot org Target Milestone: --- Having a core file, it would be handy to assemble a debugable executable with debuginfod client. I mean downloading both executables/shared libs and corresponding debug info for these modules: Example: $ eu-unstrip -n --core 12sp3-sssd.core.715 0x40+0x213000 41b05d41005e68f89b5422f1683b26c332f2d2e6@0x400264 - - /usr/sbin/sssd ... $ ls -l /usr/sbin/sssd ls: cannot access '/usr/sbin/sssd': No such file or directory $ debuginfod-find executable 41b05d41005e68f89b5422f1683b26c332f2d2e6 /home/marxin/.cache/debuginfod_client/41b05d41005e68f89b5422f1683b26c332f2d2e6/executable $ debuginfod-find debuginfo 41b05d41005e68f89b5422f1683b26c332f2d2e6 /home/marxin/.cache/debuginfod_client/41b05d41005e68f89b5422f1683b26c332f2d2e6/debuginfo -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/27573] eu-unstrip: assemble debugable executable for a core file
https://sourceware.org/bugzilla/show_bug.cgi?id=27573 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- I assume this would be some kind of "pack" command? Which would pack all relevant files, executables and debuginfo together into one directory? Maybe it should be an extension to debuginfod-find. Something like debuginfod-find pack ? Should it just be the executable? Include the debuginfo? Sources? Could you describe the use case a little more? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/27573] eu-unstrip: assemble debugable executable for a core file
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. > > Maybe it should be an extension to debuginfod-find. > Something like debuginfod-find pack ? > Should it just be the executable? Include the debuginfo? Sources? It should be likely something that can gdb properly consume. > > Could you describe the use case a little more? Imagine you receive a core file for an old supported product. You want to investigate it in gdb on a different machine (with a more recent OS) and you want to get all the needed debugging information from a debuginfod server. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/27573] eu-unstrip: assemble debugable executable for a core file
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 connectivity of her own access a cache of debug content ... perhaps transmit a tarball of $HOME/.cache/debuginfod along with the core dump? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/27573] eu-unstrip: assemble debugable executable for a core file
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.
How to specify location of shared libraries for core file?
Hi, It is possible to specify the location of shared libraries when reporting/attaching to a core file? The problem I am having is that when the core is moved to another machine the location of the shared libraries reported in its NOTE segments (and also the r_debug and link maps) are no longer correct and therefore when calling dwfl_core_file_report() and dwfl_core_file_attach() it doesn't correctly populate the location of all the modules so symbols and backtracking cannot be done. I tried to set up a search path using the "debuginfo_path" string in the callbacks for dwfl_begin() but it didn't have any effect. Could you please advise or point me in the general route of how this could be solved? Thanks a lot in advance! Kind regards, Pablo Galindo Salgado
