Bug 1394759 - [RFE] Add support for compressed debug sections.
Summary: [RFE] Add support for compressed debug sections.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-14 12:13 UTC by Vít Ondruch
Modified: 2019-04-05 11:12 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-05 11:12:20 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Vít Ondruch 2016-11-14 12:13:52 UTC
Description of problem:
Recently, there have started to appear weird messages in the build output of development snapshot of Ruby [1]:

```
... snip ...

+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 /builddir/build/BUILD/ruby-2.4.0-r56693

... snip ...

extracting debug info from /builddir/build/BUILDROOT/ruby-2.4.0-0.1.r56693.fc26.x86_64/usr/lib64/libruby.so.2.4.0
/usr/lib/rpm/debugedit: /builddir/build/BUILDROOT/ruby-2.4.0-0.1.r56693.fc26.x86_64/usr/lib64/libruby.so.2.4.0: DWARF version 0 unhandled
extracting debug info from /builddir/build/BUILDROOT/ruby-2.4.0-0.1.r56693.fc26.x86_64/usr/bin/ruby-mri

... snip ...

dwz: ./usr/lib64/libruby.so.2.4.0.debug: DWARF version 0 unhandled

... snip ...

```


This was apparently introduced by upstream commit [2], which adds "--compress-debug-sections=zlib" as one of linker options.

I am not expert in this area, but I am afraid that due to this, the debug data are not properly properly stripped and stored in -debuginfo subpackage.




Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
"DWARF version 0 unhandled" appears in build log.

Expected results:
"DWARF version 0 unhandled" does not appear in build log.


Additional info:


[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=16383886
[2] https://github.com/ruby/ruby/commit/a40d95c48fa7e7974feb294abca8af34e299d109

Comment 1 Panu Matilainen 2016-11-14 12:25:00 UTC
This would be Mark's territory, cc'd...

Comment 2 Mark Wielaard 2016-11-14 12:36:50 UTC
--compress-debug-sections=zlib doesn't really make sense when using dwz. And various tools don't support it anyway. It causes slow startup of tracing, performance or debugging tools using more memory.

elfutils 0.165+ does support compressed debug sections (both the new gabi zlib and gnu zlib styles) but dwz doesn't.

On Fedora binutils compressed debug sections are disabled by default, so it shouldn't be an issue there. If you are seeing this issue on Fedora then it is a bug in the binutils package (or the package/build accidentally enabled it).

In other cases it is probably best to just always make sure the sections are uncompressed running eu-elfcompress --type=none FILE.

Comment 3 Vít Ondruch 2016-11-14 13:03:40 UTC
(In reply to Mark Wielaard from comment #2)
> On Fedora binutils compressed debug sections are disabled by default, so it
> shouldn't be an issue there. If you are seeing this issue on Fedora then it
> is a bug in the binutils package (or the package/build accidentally enabled
> it).

This is the upstream commit which enables the compressed debug sections:

https://github.com/ruby/ruby/commit/a40d95c48fa7e7974feb294abca8af34e299d109

> In other cases it is probably best to just always make sure the sections are
> uncompressed running eu-elfcompress --type=none FILE.

Why this is not done by default, if the tooling discovers there is compressed debug info?

Comment 4 Mark Wielaard 2016-11-14 13:14:20 UTC
(In reply to Vít Ondruch from comment #3)
> (In reply to Mark Wielaard from comment #2)
> > On Fedora binutils compressed debug sections are disabled by default, so it
> > shouldn't be an issue there. If you are seeing this issue on Fedora then it
> > is a bug in the binutils package (or the package/build accidentally enabled
> > it).
> 
> This is the upstream commit which enables the compressed debug sections:
> 
> https://github.com/ruby/ruby/commit/a40d95c48fa7e7974feb294abca8af34e299d109

Ah good. Just disabled that for the fedora package then.

> > In other cases it is probably best to just always make sure the sections are
> > uncompressed running eu-elfcompress --type=none FILE.
> 
> Why this is not done by default, if the tooling discovers there is
> compressed debug info?

Because most tooling doesn't deal with compressed ELF sections. Compressed ELF sections and eu-elfcompress is relatively new (only a couple of months since the first stable release). So it never has been an issue. And if people do use compressed ELF sections it exposes issues like this. Personally I would encourage people to disable and ignore it.

Comment 5 Vít Ondruch 2016-11-14 13:23:05 UTC
(In reply to Mark Wielaard from comment #4)
> (In reply to Vít Ondruch from comment #3)
> > (In reply to Mark Wielaard from comment #2)
> > > On Fedora binutils compressed debug sections are disabled by default, so it
> > > shouldn't be an issue there. If you are seeing this issue on Fedora then it
> > > is a bug in the binutils package (or the package/build accidentally enabled
> > > it).
> > 
> > This is the upstream commit which enables the compressed debug sections:
> > 
> > https://github.com/ruby/ruby/commit/a40d95c48fa7e7974feb294abca8af34e299d109
> 
> Ah good. Just disabled that for the fedora package then.

I'm asking upstream to make it optional:

https://bugs.ruby-lang.org/issues/12934

I will also forward there this entire thread, may be they decide to revert it ;)


> > > In other cases it is probably best to just always make sure the sections are
> > > uncompressed running eu-elfcompress --type=none FILE.
> > 
> > Why this is not done by default, if the tooling discovers there is
> > compressed debug info?
> 
> Because most tooling doesn't deal with compressed ELF sections. Compressed
> ELF sections and eu-elfcompress is relatively new (only a couple of months
> since the first stable release). So it never has been an issue.
> And if people do use compressed ELF sections it exposes issues like this.

So my question is will you eventually support this (i.e. keep this RFE open), or are you going to reject this based on the statement below? :)

> Personally I would encourage people to disable and ignore it.

Comment 6 Mark Wielaard 2016-11-14 15:21:15 UTC
(In reply to Vít Ondruch from comment #5)
> > > > In other cases it is probably best to just always make sure the sections are
> > > > uncompressed running eu-elfcompress --type=none FILE.
> > > 
> > > Why this is not done by default, if the tooling discovers there is
> > > compressed debug info?
> > 
> > Because most tooling doesn't deal with compressed ELF sections. Compressed
> > ELF sections and eu-elfcompress is relatively new (only a couple of months
> > since the first stable release). So it never has been an issue.
> > And if people do use compressed ELF sections it exposes issues like this.
> 
> So my question is will you eventually support this (i.e. keep this RFE
> open), or are you going to reject this based on the statement below? :)
> 
> > Personally I would encourage people to disable and ignore it.

The real "fix" would be to get all tools, like dwz in this case, to handle it. Adding an eu-elfcompress --type=none call for all files that rpm might feed to tools that manipulate ELF files is kind of a kludge IMHO. Better done at the package level if they have to deal with compressed ELF sections anyway. But maybe the rpm maintainers might decide that is a good thing. I won't close this RFE myself.

Comment 7 Vít Ondruch 2016-11-14 15:46:46 UTC
(In reply to Mark Wielaard from comment #6)

Thx for the explanation. I forwarded your comments to Ruby upstream and will disable the compression.

> But maybe the rpm maintainers might decide that is a good thing. I
> won't close this RFE myself.

As for myself, the debug info was transparent to me so far and I would prefer to keep it that way, hence I'd love to see the compressed debug sections supported, no matter if that means to uncompress them or whatever else is deemed appropriate for packaging.

Comment 8 Panu Matilainen 2019-04-05 11:12:20 UTC
In reality, if Mark says this is not the right thing to do, the rest of us are not going to disagree and don't really have a sufficient clue about debug sections to add support even if we did. Might just as well close this.


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