[Solved] Extensions sizes growth

[jazzbiker]

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:

Code: [Select]

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.

[Rich]

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.

[jazzbiker]

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

Code: [Select]

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.

[Rich]

Hi jazzbiker
If you run a  diff  on  elf_i386.xbn  from TC10, 11, and 12 are they different?

[jazzbiker]

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.

[jazzbiker]

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:

Code: [Select]

--- 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?

[Rich]

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:

Code: [Select]

size -A PROGRAMDoes it have a large section called  gnu.build.attributes ?

Try appending this to  LDFLAGS = :

Code: [Select]

-Wl,-z,noseparate-codeSee if that make TC12 programs any smaller.

[jazzbiker]

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:

Code: [Select]

--- 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.

[jazzbiker]

.text is bloated with non-existent exceptions handling?

[Rich]

Hi jazzbiker
Does adding this to your  cflags  reduce the size any:

Code: [Select]

-fno-asynchronous-unwind-tables
And maybe also:

Code: [Select]

-fno-unwind-tables
Also, this makes for some interesting reading:
https://stackoverflow.com/questions/26300819/why-gcc-compiled-c-program-needs-eh-frame-section

[jazzbiker]

Hi, Rich!

These options really squeeze .eh_frame sections!

Code: [Select]

.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!

[jazzbiker]

Rich, can You please mark the thread as solved?

[Rich]

Hi jazzbiker
So marked.