Bug 1465997
Summary: | Need a way to exclude sections from eu-strip | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Josh Stone <jistone> |
Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | ignatenko, kardos.lubos, mjw, packaging-team-maint, vmukhame |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | rpm-4.13.0.1-32.fc27 elfutils-0.169-4.fc27 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-07-18 15:34:54 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Josh Stone
2017-06-28 16:42:42 UTC
There is eu-strip -g which only strips .debug sections. But that keeps all other non-allocated sections. Most of which aren't needed at runtime. So it looks like we would want to have an eu-strip option --keep-section=SECTION that would not strip a named (unallocated) section, even if it would be stripped otherwise. Only tricky thing about that is how it would interact with symbol sections (would it prevent any symbols to be stripped from that section?) Do you know how other distributions do this for rust based packages? What exactly is this .rustc meta-data? And if it isn't needed at runtime, why is it embedded into the main shared library. If it is only needed during compilation can't it go into a separate file in the -devel package, together with the headers, etc.? You say rustc currently doesn't know how to lookup this data except by looking at the runtime shared library object. But how hard would it be to properly separate it out? How is it different from e.g. header files also needed during build time? You see it would always be a dependency of rustc anyway. But what about people who don't install rustc, but only run binaries created by the rust toolchain? It almost sounds like what you call a shared object library (.so) is in fact really not a shared library at all? But maybe I misunderstand the working of shared libraries in the rust toolchain. Yes, 'eu-strip -g' is effectively what I'm using now via _find_debuginfo_opts. I don't know how other distros strip debuginfo. The .rustc metadata contains everything about a library that can't be plain symbols and object code. It's all the Rust-level type information, as well as internal representations of generic code that hasn't been monomorphized (instantiated to particular types) yet. It's similar in concept to C++ template headers, except Rust doesn't use separate source+headers like that. It's not needed by any running program, thus unallocated, but only needed to link a program with that library. It's perhaps misleading to call these shared libraries a Rust "runtime", because we only ship them for use by the rustc compiler itself. Every other Rust program is required to statically link the standard library, since there's no stable ABI. (Let's not get into the ABI discussion here.) The only time something other than the compiler will link to the shared libraries is for compiler plugins, which we only build and run transitively as part of package builds, never shipped. So these shared libraries are only shipped for rustc itself, and we only need their .rustc metadata for compiler plugins. If we somehow split that data into a separate -devel package, we would still have to require that as a dependency of rustc, so there would be no benefit to how rust is installed (as I said before). I find it frustrating to nitpick the way Rust is doing things here. I think that the *generic* request perfectly reasonable, to just give some control to keep unusual sections that the user knows are important, for whatever reason. (In reply to Josh Stone from comment #2) > I find it frustrating to nitpick the way Rust is doing things here. I think > that the *generic* request perfectly reasonable, to just give some control > to keep unusual sections that the user knows are important, for whatever > reason. Sorry about that. Yes, it is a reasonable request to have a way to not strip a non-allocated section away into a separate .debug file. Please don't see my nitpicking as denying the request. But it is interesting to know the specific reasons for the request. Because I believe the real issue is debuginfo vs static linking. And that isn't rust(c) specific. If these .so files are really just .a archives then we might want to think about a more generic solution for any toolchain that does help with linking debuginfo correctly into the right binaries. So forgive me for asking yet another question. But how does the debuginfo from the shared/static (standard) library end up discoverable to a debugger, profiler or tracer that might need to look at it to map an code/address range to specific sources or data types? So, for more context, maybe related: Bug 766156 - eu-strip doesn't handle ar archive library Bug 1395286 - elfutils: Support rewriting source file paths in static libraries Thanks Mark. (In reply to Mark Wielaard from comment #3) > So forgive me for asking yet another question. But how does the debuginfo > from the shared/static (standard) library end up discoverable to a debugger, > profiler or tracer that might need to look at it to map an code/address > range to specific sources or data types? The shared libraries do contain some real .text code, with corresponding .debug sections, and it works totally fine with debuggers to strip that in that normal way. The generic stuff in .rustc is not really compiled yet, so it doesn't have debuginfo. When you link that and get generics monomorphized into real code, you'll get debuginfo referencing the library's sources in that target too. This is OK for us because again, the only stuff we *ship* this way is all part of the rust srpm, so they share rust-debuginfo. For the static libraries (*.rlib) it's uglier. Then we have a few normal *.o entries and a few rust specific entries, e.g. > $ ar t /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-49022a8a9be64aa2.rlib > std-49022a8a9be64aa2.0.o > atomic.o > dwarf.o > fileline.o > posix.o > print.o > sort.o > state.o > backtrace.o > simple.o > elf.o > mmapio.o > mmap.o > rust.metadata.bin > std-49022a8a9be64aa2.0.bytecode.deflate rpmbuild unconditionally strips static archives, so we lose any debuginfo in those *.o. It also throws warnings about those two unrecognized entries. Then when we statically link a rust program to this, we get some code from the *.o without debuginfo, and some monomorphized code that does have debuginfo referencing 'std' source files. But those source files don't exist in the program's own debuginfo package. The workaround I use is to manually install rust-debuginfo and set GDB to search for the program's sources in that path too. Since the distro generally doesn't give *any* debuginfo for statically linked libraries, this manual step is gross but still better than nothing. Proposed upstream elfutils patch: strip: Add --keep-section=SECTION and --remove-section=SECTION. https://sourceware.org/ml/elfutils-devel/2017-q3/msg00007.html Proposed rpm patch: find-debuginfo.sh: Add --keep-section and --remove-section for eu-strip. http://lists.rpm.org/pipermail/rpm-maint/2017-July/005904.html With that you can: -%global _find_debuginfo_opts -g +%global _find_debuginfo_opts --keep-section .rustc elfutils patch included in elfutils-0.169-4.fc27. rpm patch submitted, will include in fedora rawhide when accepted upstream. Added upstream and in rpm-4.13.0.1-32.fc27 |