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/cover.1726268190.git.jpoimboe@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

Hi!

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

Control: tag -1 - moreinfo
Hi,

Thank you for pointer.

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

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…
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?
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.

Sebastian

Hi,

just wanted to add there is an article on lwn
https://lwn.net/Articles/1029189/

about work in the linux kernel to get this support into perf. It also
mentions that V3 the Sframe format is in the work with the goal of
deployment before SFrame is widely used.
Sebastian

(Re-adding the moreinfo, because the intention was to track the
 missing information from Debian at large.)

Hi!

Thanks, for the feedback! And sorry, I guess I should have made this
explicit, and thought it would be clear from the FAQ entry, that I'd
like to see a discussion on debian-devel on enabling this by default,
and whether people have concerns about this.

I though this might be coming in parallel (and I think that's why I
didn't reply at the time), but I don't recall seeing one. If there has
been that I've missed, I'd appreciate a pointer!

Thanks,
Guillem