Control: tag -1 moreinfo (Re-adding the moreinfo, because the intention was to track the missing information from Debian at large.)
Hi! On Fri, 2024-12-20 at 22:10:15 +0100, Sebastian Andrzej Siewior wrote: > Control: tag -1 - moreinfo > > On 2024-12-17 02:19:30 [+0100], Guillem Jover wrote: > > 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, 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
