Build with -ffunction-sections -fdata-sections -Wl,–gc-sections ? #18579

1. 
   sipa commented at 10:50 pm on April 9, 2020: member

   Due to the organization of our codebase we tend to build and link in a bunch of functions into the binaries that aren’t actually used.

   I’ve tried building with -ffunction-sections -fdata-sections -Wl,--gc-sections, and it reduces bitcoind (after stripping) from 7.2 MB to 6.9 MB. The bitcoin-wallet tool goes from 3.5 MB to 1.3 MB.

   Any reason why we don’t do this? I only find a mention in #4042, but it’s not clear how relevant that is to me.

2. sipa added the label Feature on Apr 9, 2020
3. 
   sipa commented at 10:51 pm on April 9, 2020: member

   Ping @theuni.
4. fanquake added the label Build system on Apr 9, 2020
5. sipa removed the label Feature on Apr 9, 2020
6. 
   fanquake commented at 10:56 pm on April 9, 2020: member

   I’ve got a branch that does link time garbage collection, using pretty much the same flags, and have seen similar binary size savings. If wanted this is probably something we could add to the Guix / Gitian descriptors.
7. 
   ryanofsky commented at 11:26 pm on April 9, 2020: contributor

   This seems ok, but IIRC if you build with -ffunction-sections and -fdata-sections it mask link errors that would happen without these flags, because the linker won’t complain about missing symbols from the sections that are skipped. It might be better to reserve these flags for release builds, otherwise it could be annoying when local builds succeed but appveyor / travis builds have link errors
8. 
   sipa commented at 11:30 pm on April 9, 2020: member

   @ryanofsky That’s a good point. Maybe just something to do in Gitian/Guix.
9. 
   laanwj commented at 10:06 am on April 13, 2020: member

   @ryanofsky That’s a good point. Maybe just something to do in Gitian/Guix.

   Agree. I kind of like this, it’s a safer (and link-time much faster) option than going full LTO but still manages to get rid of a lot of cruft in the binary.

10. 
    practicalswift commented at 7:08 pm on April 13, 2020: contributor

    I kind of like this, it’s a safer (and link-time much faster) option than going full LTO but still manages to get rid of a lot of cruft in the binary.

    Just to fully understand the argument: safer than full LTO in what regard?

11. 
    sipa commented at 8:21 pm on April 13, 2020: member

    LTO has historically be a source of bugs in compilers - it’s improved a lot of course, and we should evaluate when it’s mature enough to enable. But that’s a far bigger change than enabling link-time GC.

    In addition, experiments in the past have shown that LTO wasn’t always a performance gain (it has been a while, the situation may be better now, but even then, maybe we only want it for certain compiler versions etc…).

12. fanquake referenced this in commit ac21090f20 on Apr 28, 2020
13. sidhujag referenced this in commit d861869e55 on Apr 28, 2020
14. fanquake referenced this in commit 681b25e3cd on Nov 25, 2021
15. sidhujag referenced this in commit 67658eec7d on Nov 25, 2021
16. PastaPastaPasta referenced this in commit 0ec2a3b640 on Jun 19, 2022
17. PastaPastaPasta referenced this in commit f7a94b58d4 on Jun 19, 2022
18. 
    fanquake commented at 11:33 am on August 3, 2022: member

    Going to close this for now, given that hopefully we’ll be using in an upcoming release (not 24.0). #18605 was an attempt to add the garbage collection link flags.
19. fanquake closed this on Aug 3, 2022

    ---

20. bitcoin locked this on Aug 3, 2023

Contributors
sipa fanquake ryanofsky laanwj practicalswift

Labels
Build system