Control: tag -1 - moreinfo On 2024-12-17 02:19:30 [+0100], Guillem Jover wrote: > > Hi! 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 Thank you for pointer. > 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? This is debug functionality, I guess same story as with "-g" or the frame pointer functionality in general. > * 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… > * 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? > * 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. > Thanks, > Guillem Sebastian
