Bug#1088320: libdpkg-perl: Enable generation of sframes.

[Sebastian Andrzej Siewior]

Package: libdpkg-perl
Version: 1.22.11
Severity: normal
Tags: sid patch

SFrame is a stack trace format.
https://sourceware.org/binutils/wiki/sframe

This can be generated since binutils 2.41.
There are patches against the Linux kernel to let perf use the new
format
https://lore.kernel.org/all/***@kernel.org/

It would be nice if the compiled binaries could create the additional
sframe so it is there and can be used to generate backtraces. This can
coexist with the eh_frame.

Sebastian

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

Post by Sebastian Andrzej Siewior
Package: libdpkg-perl
Version: 1.22.11
Severity: normal
Tags: sid patch
SFrame is a stack trace format.
https://sourceware.org/binutils/wiki/sframe
This can be generated since binutils 2.41.
There are patches against the Linux kernel to let perf use the new
format
It would be nice if the compiled binaries could create the additional
sframe so it is there and can be used to generate backtraces. This can
coexist with the eh_frame.

Thanks for the patch! This would involve the usual procedure to add
flags to the default set, as mentioned here:

https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F

Notice that not all are supposed to be requirements, which depends on
the expected effect of the flags at hand.

In this case though my first questions would be:

* Why are these not enabled by default in binutils upstream?
* How much bigger do objects get after this?
* Can this increase linker times substantially?
* Is there any downside, like backwards compat issues or similar?

Thanks,
Guillem

[Sebastian Andrzej Siewior]

Control: tag -1 - moreinfo

Post by Guillem Jover
Hi!

Hi,

Post by Guillem Jover
Thanks for the patch! This would involve the usual procedure to add
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F

Thank you for pointer.

Post by Guillem Jover
Notice that not all are supposed to be requirements, which depends on
the expected effect of the flags at hand.
* Why are these not enabled by default in binutils upstream?

This is debug functionality, I guess same story as with "-g" or the
frame pointer functionality in general.

Post by Guillem Jover
* How much bigger do objects get after this?

It is always referred to as "low overhead stack straces". Here is a dpkg
example. I rebuilt 1.22.11 with and without the sframe.

orig sframe + % +bytes file
322576 359512 ~11.5 36936 usr/bin/dpkg
174624 203368 ~16.5 28744 usr/bin/dpkg-deb
162584 187232 ~15.5 24648 usr/bin/dpkg-divert
166672 195416 ~17.2 28744 usr/bin/dpkg-query
55632 63896 ~14.9 8264 usr/bin/dpkg-realpath
137712 158264 ~14.9 20552 usr/bin/dpkg-split
72192 80456 ~11.4 8264 usr/bin/dpkg-statoverride
92656 105016 ~13.3 12360 usr/bin/dpkg-trigger
59712 63880 ~ 7.0 4168 usr/bin/update-alternatives
44464 48632 ~ 9.4 4168 usr/sbin/start-stop-daemon

For dpkg, I also noticed
470336 normal usr/lib/debug/.build-id/99/9b34fb6dabbe5d09befb4cae69906981259a2d.debug
508248 sframe usr/lib/debug/.build-id/73/79b3f024323c03b3133329de18f56b66d9fa47.debug

37912 byte increase in the debug file. So I guess the other debug files
increase in a similar fashion. Not sure why…

Post by Guillem Jover
* Can this increase linker times substantially?

I don't think so since it some metadata. I am however not in the
position to make guesses. Is there a way to make a test?

Post by Guillem Jover
* Is there any downside, like backwards compat issues or similar?

Not that I am aware of. It was added in binutils initially as version 1
and then replaced with version 2 (current bintuils) in a backwards
compatible way. Version 3 is in development and should follow the same
way.

Post by Guillem Jover
Thanks,
Guillem

Sebastian