@kodabb I don't think it's a problem to satisfy @laurentbercot's request, but 3% in static libc size is prob. <0.1% final static binary size
-
-
Replying to @RichFelker
@RichFelker Depends on the size of binaries. I usually make *very* small binaries, where the proportional increase is likely bigger.2 replies 0 retweets 0 likes -
Replying to @laurentbercot
@laurentbercot@RichFelker can you please provide a benchmark about it? Sounds strange to have such impact...1 reply 0 retweets 0 likes -
Replying to @lu_zero_
@lu_zero_@laurentbercot PIC is historically quite costly on some targets, but better now.3 replies 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@lu_zero_@laurentbercot It was quite expensive on i386 due to scarce general purpose registers and the poor GCC implementation.1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
@RichFelker@lu_zero_@laurentbercot GCC 5 included substantial PIC optimizations for archs without PIC support: https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode ….2 replies 1 retweet 0 likes -
Replying to @CopperheadOS
@RichFelker@lu_zero_@laurentbercot And it also introduced copy relocations for x86_64, reducing the performance cost to essentially zero.1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
@CopperheadSec@lu_zero_@laurentbercot Introducing copy reloc was a nasty regression in PIE. B4 that, PIE got rid of copy-reloc ABI leakage1 reply 0 retweets 0 likes
@CopperheadSec @lu_zero_ @laurentbercot In any case, using global vars from a library in the main program is horrible API design.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.