Tiny Core Base > TCB Bugs

filetool.sh TC 10.1 trivial display bug: trailing slash in output

<< < (3/5) > >>

jazzbiker:

--- Quote from: Rich on August 12, 2019, 11:56:15 AM --- My guess is the current compiler has some "enhancements" not present
in the TC4 version that add some overhead.

--- End quote ---

Thanks for Your answer, Rich.
My feeling is that sometimes tcc is the real alternative to gcc - for simple programs.

jazzbiker:
Continuing off-topic:


--- Code: ---tc@box:/tmp$ uname -a
Linux box 4.19.10-tinycore #1999 SMP Tue Dec 18 13:36:47 UTC 2018 i686 GNU/Linux
tc@box:/tmp$ wget http://distro.ibiblio.org/tinycorelinux/4.x/x86/release/src/3.
x/rotdash.c
Connecting to distro.ibiblio.org (152.19.134.43:80)
rotdash.c            100% |********************************|   317  0:00:00 ETA
tc@box:/tmp$ tce-load -i tcc
tcc is already installed!
tc@box:/tmp$ tcc -v
tcc version 0.9.26 (i386 Linux)
tc@box:/tmp$ tcc -o rotdash rotdash.c
tc@box:/tmp$ ls -l rotdash*
-rwxr-xr-x    1 tc       staff         2816 Aug 13 13:49 rotdash
-rw-r--r--    1 tc       staff          317 Aug 13 13:48 rotdash.c
tc@box:/tmp$ tce-load -i sstrip
sstrip is already installed!
tc@box:/tmp$ sstrip rotdash
tc@box:/tmp$ ls -l rotdash*
-rwxr-xr-x    1 tc       staff         1312 Aug 13 13:49 rotdash
-rw-r--r--    1 tc       staff          317 Aug 13 13:48 rotdash.c

--- End code ---

Rich:
Hi jazzbiker

--- Quote from: Rich on August 12, 2019, 11:56:15 AM ---I honestly don't know why the executable is so much larger. My guess is the current compiler has some "enhancements" not present
in the TC4 version that add some overhead. ...
--- End quote ---
I don't know why it's happening, but I know what's happening. I looked through the stripped file and found 3 large blocks of zeros.
Each block was over 3500 bytes long.


--- Quote from: Rich on August 11, 2019, 11:59:18 PM --- ... In TC10 I can't get the size under 12324 bytes. ...
--- End quote ---
Subtracting 3 times 3500 from 12324 leaves 1824 which suggests all the growth consists of zero padding.

jazzbiker:

--- Quote from: Rich on August 14, 2019, 02:14:56 AM ---
I don't know why it's happening, but I know what's happening. I looked through the stripped file and found 3 large blocks of zeros.
Each block was over 3500 bytes long.


--- End quote ---

Some initialized variables. They may be examined better before stripping, probably.
But tcc gives 1312 total size )

jazzbiker:

--- Code: ---tc@box:/tmp/rotdash$ nm  -n -S rotdash
         U access@@GLIBC_2.0
         U chdir@@GLIBC_2.0
         U fflush@@GLIBC_2.0
         w __gmon_start__
         U __libc_start_main@@GLIBC_2.0
         U printf@@GLIBC_2.0
         U usleep@@GLIBC_2.0
08049000 T _init
08049090 T _start
080490c0 00000004 T __x86.get_pc_thunk.bx
080490c4 t deregister_tm_clones
080490ec t register_tm_clones
08049122 t __do_global_dtors_aux
08049140 t frame_dummy
08049142 000000bb T main
080491fd 0000004f T __libc_csu_init
0804924c 00000001 T __libc_csu_fini
08049250 T _fini
0804a000 00000004 R _fp_hw
0804a004 00000004 R _IO_stdin_used
0804a014 r __FRAME_END__
0804bf04 t __frame_dummy_init_array_entry
0804bf04 t __init_array_start
0804bf08 t __do_global_dtors_aux_fini_array_entry
0804bf08 t __init_array_end
0804bf0c d _DYNAMIC
0804c000 d _GLOBAL_OFFSET_TABLE_
0804c024 D __data_start
0804c024 W data_start
0804c028 D __dso_handle
0804c02c B __bss_start
0804c02c D _edata
0804c02c 00000004 B stdout@@GLIBC_2.0
0804c02c D __TMC_END__
0804c030 00000001 b completed.6835
0804c034 B _end
--- End code ---

After _fini in text section next symbol is _fp_hw in read-only section and it is aligned on xxx000.
Then _GLOBAL_OFFSET_TABLE_ is aligned the same way.

There may be some linker switches concerning section alignment, i guess.

Th hole between __FRAME_END__ (read-only section) and __frame_dummy_init_array_entry (text section) is almost 8K.

Navigation

[0] Message Index

[#] Next page

[*] Previous page