Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: jazzbiker on May 22, 2021, 03:04:49 PM
-
Hi, Core people!
Can You please help me explain me, why the same package compiled with the same script in the different versions of TinyCore has an unstoppably growing size? Is it caused by my mistakes?
Example. I've packed vis.tcz in TC10 x86, tested it and submitted for TC11 and TC12. Building and packing was performed with the help of the same script for all versions. And resulting sizes are:
tc@box:~$ ls -l /mnt/sdb3/tce1?/optional/vis.tcz
-rw-rw-r-- 1 tc staff 139264 Aug 18 2020 /mnt/sdb3/tce10/optional/vis.tcz
-rw-rw-r-- 1 tc staff 151552 Aug 14 2020 /mnt/sdb3/tce11/optional/vis.tcz
-rw-rw-r-- 1 tc staff 176128 Apr 10 19:24 /mnt/sdb3/tce12/optional/vis.tcz
tc@box:~$ ls -l /mnt/sdb3/tce1?/optional/vis-nolua.tcz
-rw-rw-r-- 1 tc staff 106496 Aug 18 2020 /mnt/sdb3/tce10/optional/vis-nolua.tcz
-rw-rw-r-- 1 tc staff 118784 Aug 14 2020 /mnt/sdb3/tce11/optional/vis-nolua.tcz
-rw-rw-r-- 1 tc staff 135168 Apr 10 19:24 /mnt/sdb3/tce12/optional/vis-nolua.tcz
The difference is in gcc versions, sources are the same, script is the same. How this is to be interpreted? The less gcc version, the smaller binary? Is the right strategy is to choose the oldest possible version of TinyCore to build an extension?
Thanks in advance.
-
Hi jazzbiker
I think I may have covered that here:
http://forum.tinycorelinux.net/index.php/topic,23134.msg144872.html#msg144872
and continued it here:
http://forum.tinycorelinux.net/index.php/topic,23623.msg148064.html#msg148064
What a coincidence, you were involved in both threads. :)
-
Hi, Rich!
Thank You for the answer and for the reminder, I didn't forget those threads. Your proposal of size-optimized non-default linker scripts is great, I use it every time I need to link some code :) But in this thread I compare the results of different gcc versions over the same code and the same script, meaning absolutely the same compile and link options. For clarity I rechecked with .xbn ld script fixed and result was the same. Linker options were
LDFLAGS = -Wl,-T/usr/local/lib/ldscripts/elf_i386.xbn -Wl,-z,now -Wl,-z,relro
LDFLAGS_STD = -lc
LDFLAGS_AUTO = -Wl,--gc-sections -pie
for all three attempts.
And explicit requirement of .xbn script had almost no effect on the sizes of extensions. I don't know what the other options mean, but they optimize the size very well, as we can see.
I feel that more attention is to be paid to gcc version to use.
-
Hi jazzbiker
If you run a diff on elf_i386.xbn from TC10, 11, and 12 are they different?
-
Hi, Rich!
I attach the diff of elf_i386.xbn files taken from binutils of TC10 and TC12. If You will find substantial differences, please point them at, I see only additional spaces, renamed directories and "do not"s instead of "don't"s.
-
I performed some experiments to know the real memory consumption of the binaries. In both TC versions (10 and 12) I:
1. run vis (in fact vis-nolua)
2. get its PID
3. cat /proc/$PID/smaps | grep -A 1 'vis-nolua' > visXX.segm
and then diff'ed the maps I got:
--- vis10.segm
+++ vis12.segm
@@ -1,14 +1,14 @@
-004e2000-004e7000 r--p 00000000 07:1d 4 /tmp/tcloop/vis-nolua/usr/local/bin/vis-nolua
+00461000-00466000 r--p 00000000 07:1f 4 /tmp/tcloop/vis-nolua/usr/local/bin/vis-nolua
Size: 20 kB
--
-004e7000-0050b000 r-xp 00005000 07:1d 4 /tmp/tcloop/vis-nolua/usr/local/bin/vis-nolua
-Size: 144 kB
+00466000-00493000 r-xp 00005000 07:1f 4 /tmp/tcloop/vis-nolua/usr/local/bin/vis-nolua
+Size: 180 kB
--
-0050b000-00511000 r--p 00029000 07:1d 4 /tmp/tcloop/vis-nolua/usr/local/bin/vis-nolua
-Size: 24 kB
+00493000-004a0000 r--p 00032000 07:1f 4 /tmp/tcloop/vis-nolua/usr/local/bin/vis-nolua
+Size: 52 kB
--
-00512000-00515000 r--p 0002f000 07:1d 4 /tmp/tcloop/vis-nolua/usr/local/bin/vis-nolua
+004a0000-004a3000 r--p 0003e000 07:1f 4 /tmp/tcloop/vis-nolua/usr/local/bin/vis-nolua
Size: 12 kB
--
-00515000-00516000 rw-p 00032000 07:1d 4 /tmp/tcloop/vis-nolua/usr/local/bin/vis-nolua
+004a3000-004a4000 rw-p 00041000 07:1f 4 /tmp/tcloop/vis-nolua/usr/local/bin/vis-nolua
Size: 4 kB
The difference in the code segment size (r-xp attributes) is clear to see.
So the issue is not only in the .elf size.
Maybe newer gcc version places some information in the .output .elf, which is not understandable by sstrip?
-
Hi jazzbiker
Most of the changes shown in the xbn.diff involve minor added whitespace. However, there was one addition near the
end that might be part of the issue:
+ .gnu.build.attributes : { *(.gnu.build.attributes .gnu.build.attributes.*) }
Compile a program without stripping it. Then run this on the program:
size -A PROGRAMDoes it have a large section called gnu.build.attributes ?
Try appending this to LDFLAGS = :
-Wl,-z,noseparate-codeSee if that make TC12 programs any smaller.
-
Hi, Rich!
There is no "gnu.build.attributes" section.
Here is diff of "size -A vis-lua" of unstripped versions built under tc10 and tc12:
--- tc10.size
+++ tc12.size
@@ -5,26 +5,27 @@
.hash 2376
.gnu.hash 52
.dynsym 3296
-.dynstr 2458
+.dynstr 2464
.gnu.version 412
-.gnu.version_r 160
+.gnu.version_r 176
.rel.dyn 15192
.rel.plt 16
.init 32
.plt 48
.plt.got 8
-.text 174946
+.text 219689
.fini 20
-.rodata 24316
-.eh_frame 4
+.rodata 24128
+.eh_frame_hdr 4788
+.eh_frame 28444
.init_array 4
.fini_array 4
-.data.rel.ro 12124
-.dynamic 296
+.data.rel.ro 12136
+.dynamic 288
.got 820
.data 840
-.bss 5128
-.comment 17
-Total 242620
+.bss 5120
+.comment 18
+Total 320422
As You can see, .text is significantly greater for tc12 and some .eh_frame and .eh_frame_hdr appeared.
Searching on those .eh_frame tells, that it is exception handling related section :( What the hell exceptions in pure C?
But regardless of those "exceptions", .text section is significantly fatter.
-
.text is bloated with non-existent exceptions handling?
-
Hi jazzbiker
Does adding this to your cflags reduce the size any:
-fno-asynchronous-unwind-tables
And maybe also:
-fno-unwind-tables
Also, this makes for some interesting reading:
https://stackoverflow.com/questions/26300819/why-gcc-compiled-c-program-needs-eh-frame-section
-
Hi, Rich!
These options really squeeze .eh_frame sections! :)
.eh_frame_hdr 68 78400
.eh_frame 256 78468
Thanks a lot!
But .text remains fat :( Probably optimally fat :)
Thank You for interesting link!
Edit: sorry, no fat at all! I was not aware, that these binaries were not striped. After sstriping I've got exactly the same sized extensions as for TC10! Great, nice, wonderfl!
Thank You very much!
-
Rich, can You please mark the thread as solved?
-
Hi jazzbiker
So marked. :)