Bug 1661512 - rpm: Add --g-libs option that does eu-strip -g only on libraries
Summary: rpm: Add --g-libs option that does eu-strip -g only on libraries
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: debugedit
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mark Wielaard
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1663264
TreeView+ depends on / blocked
 
Reported: 2018-12-21 12:28 UTC by Florian Weimer
Modified: 2021-05-20 11:58 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1663264 (view as bug list)
Environment:
Last Closed: 2021-05-20 11:57:29 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1186563 0 unspecified CLOSED find-debuginfo.sh doesn't pass _find_debuginfo_opts -g to eu-strip for application/x-executable 2021-02-22 00:41:40 UTC

Internal Links: 1186563

Description Florian Weimer 2018-12-21 12:28:44 UTC
glibc relied on the behavior that bug 1186563 changed: We use -g, but do not want to apply it to programs.

It looks like this will need some find-debuginfo.sh change.  (I am not interested in a hack that puts custom binaries on PATH or something like that.)

Comment 1 Florian Weimer 2019-04-09 12:03:57 UTC
Would it be possible to add --g-libs support to rawhide at least?  Thanks.

Comment 2 Panu Matilainen 2019-04-10 08:14:58 UTC
Added in rpm-4.14.2.1-5.fc31

Comment 3 Florian Weimer 2019-04-11 10:13:22 UTC
Sorry, the patch does not work with the version of file in rawhide:

<mock-chroot> sh-5.0# file -bi /lib64/ld-2.29.9000.so 
application/x-pie-executable; charset=binary

/lib64/ld-2.29.9000.so does not have the PIE flag set:

<mock-chroot> sh-5.0# readelf -dW /lib64/ld-2.29.9000.so

Dynamic section at offset 0x29df0 contains 21 entries:
  Tag        Type                         Name/Value
 0x000000000000000e (SONAME)             Library soname: [ld-linux-x86-64.so.2]
 0x0000000000000004 (HASH)               0x2f0
 0x000000006ffffef5 (GNU_HASH)           0x3c8
 0x0000000000000005 (STRTAB)             0x810
 0x0000000000000006 (SYMTAB)             0x4c8
 0x000000000000000a (STRSZ)              564 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x2af80
 0x0000000000000002 (PLTRELSZ)           192 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0xf40
 0x0000000000000007 (RELA)               0xb38
 0x0000000000000008 (RELASZ)             1032 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffc (VERDEF)             0xa90
 0x000000006ffffffd (VERDEFNUM)          5
 0x0000000000000018 (BIND_NOW)           
 0x000000006ffffffb (FLAGS_1)            Flags: NOW
 0x000000006ffffff0 (VERSYM)             0xa44
 0x000000006ffffff9 (RELACOUNT)          41
 0x0000000000000000 (NULL)               0x0

So it the output of file is clearly wrong.  I think we really need to investigate how we can use something more reliable than file for ELF processing.

Comment 4 Panu Matilainen 2019-04-11 10:20:41 UTC
If output of file is wrong, that doesn't make the rpm patch wrong.

As for better identification of ELF objects, I'm sure everybody agrees. There's a bug for it already: 
https://bugzilla.redhat.com/show_bug.cgi?id=1609013

The problem is that I for one sure don't know how to distinguish a DSO library that is actually executable (both in permissions and having a main()) from a PIE executable, and seems file authors dont either. If somebody knows, patches welcome...

Comment 5 Mark Wielaard 2019-04-11 11:40:54 UTC
file isn't completely wrong. ld.so is an executable that is dynamically linked (so it is also a library).
Independently from the fact that we do need a better "file classifier" we might need to better define/document what -g-libs means in this case.
glibc is kind of special in that it has multiple shared libraries that are also executables:

$ file /usr/lib64/libc-2.28.so 
/usr/lib64/libc-2.28.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=245853cc14fc438740d392e5a6a4a3b5e95720e7, for GNU/Linux 3.2.0, not stripped, too many notes (256)

$ /usr/lib64/libc-2.28.so
GNU C Library (GNU libc) stable release version 2.28.
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 8.3.1 20190223 (Red Hat 8.3.1-2).
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

Comment 6 Florian Weimer 2019-04-11 12:03:05 UTC
Current Fedora binutils sets the PIE flag on PIE executables, so we have a reliable way of detecting them during the build.  Neither object you mention has this flag set.

Maybe file cannot use it in file proper, but we definitely can use it to control debuginfo stripping for Fedora builds if we write our own tool.

Comment 7 Florian Weimer 2019-06-06 12:24:23 UTC
Mark, any suggestions how to proceed here?  Should pick up eu-elfclassify again and update find-debuginfo.sh to use it if it is available?  Thanks.

Comment 8 Mark Wielaard 2019-06-27 11:13:13 UTC
(In reply to Florian Weimer from comment #7)
> Mark, any suggestions how to proceed here?  Should pick up eu-elfclassify
> again and update find-debuginfo.sh to use it if it is available?  Thanks.

Yes, I think we should. Sorry for dropping the ball on eu-elfclassify. I do think it is a good idea.
We should pick it up again. And see if we can get some rpm hacker to look at it, to see if they are happy to use it instead of parsing 'file' output.
Hint, rpm maintainers, could you take a peek at the following thread:
https://sourceware.org/ml/elfutils-devel/2019-q2/msg00018.html

Comment 9 Ben Cotton 2019-08-13 16:48:03 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 10 Carlos O'Donell 2020-03-13 12:01:42 UTC
Any status on this bug? It blocks using this functionality downstream.

Comment 11 Ben Cotton 2020-11-03 15:06:51 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 12 Ben Cotton 2021-02-09 15:09:13 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Comment 13 Panu Matilainen 2021-05-20 11:22:51 UTC
Reassigning to debugedit now that it's a separate component.

Comment 14 Florian Weimer 2021-05-20 11:57:29 UTC
We don't need this anymore for the glibc build. We use a wrapper now that inhibits debuginfo separation for ld.so, and use the default for everything else.


Note You need to log in before you can comment on or make changes to this bug.