Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
bzImage doubled in size
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
cadwal_se
n00b
n00b


Joined: 16 Feb 2018
Posts: 5
Location: Sweden

PostPosted: Fri Feb 16, 2018 4:58 pm    Post subject: bzImage doubled in size Reply with quote

Somewhere around when binutils and gcc 6.4.0 turned up the size of bzImage doubled in size for me.

Kernel 4.12.5 had previously been built, bzImage was/is about 5.5 MB with my options, but any new kernel compiles for the same version with the same config yields bzImage that is 9.5 MB.

(Later kernels is just as big, including the the new 4.9.76-r1 after I switched to the 17.0 profile.)

At the time I tried switching back to previous binutils and gcc (numbers lost since I later removed the old versions in my experimentation) but that did not change anything.

I left it alone for a while on the assumption that "later versions would fix it" ...

Things are still the same though so this time I wanted to look deeper:

So more info:

arch/x86/boot/bzImage is big because it is based on arch/x86/boot/compressed/vmlinux which is also big.

arch/x86/boot/compressed/vmlinux is created using this command during kernel build (this was for 4.14.8, pgtable_64.o does not exist in older kernels):

Code:

 ld -m elf_x86_64 -z noreloc-overflow -pie --no-dynamic-linker   -T arch/x86/boot/compressed/vmlinux.lds arch/x86/boot/compressed/head_64.o arch/x86/boot/compressed/misc.o arch/x86/boot/compressed/string.o arch/x86/boot/compressed/cmdline.o arch/x86/boot/compressed/error.o arch/x86/boot/compressed/piggy.o arch/x86/boot/compressed/cpuflags.o arch/x86/boot/compressed/early_serial_console.o arch/x86/boot/compressed/pgtable_64.o -o arch/x86/boot/compressed/vmlinux


looking at the files involved we have this:

Code:
ecce /usr/src/linux/arch/x86/boot/compressed # ls -lrt vmlinux.lds head_64.o misc.o string.o cmdline.o error.o piggy.o cpuflags.o early_serial_console.o pgtable_64.o vmlinux
-rw-r--r-- 1 root root      775 29 dec 13.48 vmlinux.lds
-rw-r--r-- 1 root root     6480 29 dec 13.48 head_64.o
-rw-r--r-- 1 root root    11976 29 dec 13.48 misc.o
-rw-r--r-- 1 root root     3480 29 dec 13.48 string.o
-rw-r--r-- 1 root root     2640 29 dec 13.48 cmdline.o
-rw-r--r-- 1 root root     1864 29 dec 13.48 error.o
-rw-r--r-- 1 root root  5905888 29 dec 13.48 piggy.o
-rw-r--r-- 1 root root      928 29 dec 13.48 cpuflags.o
-rw-r--r-- 1 root root     3440 29 dec 13.48 early_serial_console.o
-rw-r--r-- 1 root root     1312 29 dec 13.48 pgtable_64.o
-rwxr-xr-x 1 root root 12256280 29 dec 15.15 vmlinux
ecce /usr/src/linux/arch/x86/boot/compressed #


Now, piggy.o is the actual kernel (compressed) and has the same size it did before any of this happened. (there is a slight increase with every kernel as expected).

Can anyone tell me how to find out how vmlinux ends up being more than twice the size of the files it is based on? Some odd hidden default flags to ld since reading the docs on the flags used does not tell me this is a likely outcome?

Note: I have not actually tried using any of the kernels after the size increase.
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2977
Location: Germany

PostPosted: Fri Feb 16, 2018 6:27 pm    Post subject: Reply with quote

You could binwalk --extract those bzImages (and again the extracted contents) just to see if there is anything obvious. Like a built-in initramfs that could be responsible for the size.

I also had a size increase, 4.12.5 is 9.4M, 4.13.4 9.5M, but bzImage-4.15.2 is 11M. This is a static kernel (no modules, required drivers builtin) and also a built-in initramfs that didn't change in any way worth mentioning.

I assumed it's related to whatever that meltdown/spectre nonsense.
Back to top
View user's profile Send private message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 264

PostPosted: Fri Feb 16, 2018 10:00 pm    Post subject: Reply with quote

When bringing my original configuration forward, I noticed a lot of options defaulted to on, yet there was no noticeable size increase:
Code:
# du -h `find /usr/src/ -name bzImage`
6.9M   /usr/src/linux-4.14.8-gentoo-r1/arch/x86/boot/bzImage
6.8M   /usr/src/linux-4.12.12-gentoo/arch/x86/boot/bzImage
7.0M   /usr/src/linux-4.8.17-hardened-r2/arch/x86/boot/bzImage

How did you get your kernel down to 5M in the first place, if you don't mind?
Back to top
View user's profile Send private message
josephg
l33t
l33t


Joined: 10 Jan 2016
Posts: 783
Location: usually offline

PostPosted: Fri Feb 16, 2018 11:08 pm    Post subject: Re: bzImage doubled in size Reply with quote

cadwal_se wrote:
Somewhere around when binutils and gcc 6.4.0 turned up the size of bzImage doubled in size for me.

Kernel 4.12.5 had previously been built, bzImage was/is about 5.5 MB with my options, but any new kernel compiles for the same version with the same config yields bzImage that is 9.5 MB.

(Later kernels is just as big, including the the new 4.9.76-r1 after I switched to the 17.0 profile.)

my gcc is 6.4.0-r1, kernel is 4.9.76-r1, and bzImage is 2.5M. previous kernels have been smaller. i do have initramfs and also build all modules out of kernel.
Code:
-rw-r--r-- 1 root root   16154 2018-01-16 17:40 vmlinux.lds
-rw-r--r-- 1 root root    2980 2018-01-16 17:40 string.o
-rw-r--r-- 1 root root     644 2018-01-16 17:40 cpuflags.o
-rw-r--r-- 1 root root     640 2018-01-18 19:24 cmdline.o
-rw-r--r-- 1 root root    1572 2018-01-18 19:24 error.o
-rw-r--r-- 1 root root   19052 2018-02-11 19:48 misc.o
-rw-r--r-- 1 root root 2585952 2018-02-11 19:48 piggy.o
-rwxr-xr-x 1 root root 2608916 2018-02-11 19:48 vmlinux

_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey
Back to top
View user's profile Send private message
cadwal_se
n00b
n00b


Joined: 16 Feb 2018
Posts: 5
Location: Sweden

PostPosted: Sat Feb 17, 2018 11:59 am    Post subject: Reply with quote

R0b0t1 wrote:
How did you get your kernel down to 5M in the first place, if you don't mind?


I have the absolute minimum of drivers compiled in and have most of the "odd" networking and crypto stuff as modules.
Back to top
View user's profile Send private message
bunder
Bodhisattva
Bodhisattva


Joined: 10 Apr 2004
Posts: 5934

PostPosted: Sat Feb 17, 2018 1:01 pm    Post subject: Reply with quote

frostschutz wrote:
Like a built-in initramfs that could be responsible for the size.


or changing compression... xz should yield the smallest file.
Back to top
View user's profile Send private message
cadwal_se
n00b
n00b


Joined: 16 Feb 2018
Posts: 5
Location: Sweden

PostPosted: Sat Feb 17, 2018 5:20 pm    Post subject: Re: bzImage doubled in size Reply with quote

josephg wrote:

my gcc is 6.4.0-r1, kernel is 4.9.76-r1, and bzImage is 2.5M. previous kernels have been smaller. i do have initramfs and also build all modules out of kernel.
Code:
-rw-r--r-- 1 root root   16154 2018-01-16 17:40 vmlinux.lds
-rw-r--r-- 1 root root    2980 2018-01-16 17:40 string.o
-rw-r--r-- 1 root root     644 2018-01-16 17:40 cpuflags.o
-rw-r--r-- 1 root root     640 2018-01-18 19:24 cmdline.o
-rw-r--r-- 1 root root    1572 2018-01-18 19:24 error.o
-rw-r--r-- 1 root root   19052 2018-02-11 19:48 misc.o
-rw-r--r-- 1 root root 2585952 2018-02-11 19:48 piggy.o
-rwxr-xr-x 1 root root 2608916 2018-02-11 19:48 vmlinux


That is the way I would expect the file sizes to end up.

What versions of ld (and binutils) do you have?
Back to top
View user's profile Send private message
cadwal_se
n00b
n00b


Joined: 16 Feb 2018
Posts: 5
Location: Sweden

PostPosted: Sat Feb 17, 2018 8:33 pm    Post subject: Reply with quote

Ok, I have done some more checking and there is something odd going on with ld in this case...

If I remove the -pie option in the aforementioned ld command line and run it manually, the size of the intermediate vmlinux file goes down from twice the size of piggy.o to about 1.5 times the size.

And if I then let the regular make turn that into bzImage its back to its "normal" size:

Code:

-rw-r--r-- 1 root root 5547296 17 feb 21.28 ../bzImage


Mmm...

And if I go the other way with binwalk:

Code:

ecce /tmp/t # ls -lrt
totalt 15172
-rw-r--r-- 1 root root 5720624 17 feb 18.17 kernel-4.12.5-gentoo
-rw-r--r-- 1 root root 9785328 17 feb 18.26 kernel-4.9.76-gentoo-r1
ecce /tmp/t # binwalk --extract kernel-4.12.5-gentoo

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
17014         0x4276          bzip2 compressed data, block size = 900k

ecce /tmp/t # binwalk --extract kernel-4.9.76-gentoo-r1

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
16502         0x4076          bzip2 compressed data, block size = 900k

ecce /tmp/t # ls -l
totalt 15180
-rw-r--r-- 1 root root 5720624 17 feb 18.17 kernel-4.12.5-gentoo
drwxr-xr-x 2 root root    4096 17 feb 18.43 _kernel-4.12.5-gentoo.extracted
-rw-r--r-- 1 root root 9785328 17 feb 18.26 kernel-4.9.76-gentoo-r1
drwxr-xr-x 2 root root    4096 17 feb 18.43 _kernel-4.9.76-gentoo-r1.extracted
ecce /tmp/t # ls -l _kernel-4.12.5-gentoo.extracted/
totalt 18628
-rw------- 1 root root 19048560 17 feb 18.43 4276
ecce /tmp/t # ls -l _kernel-4.9.76-gentoo-r1.extracted/
totalt 18516
-rw------- 1 root root 18933872 17 feb 18.43 4076


And if I go one step further (skipping the long output from binwalk which appears fairly identical in both cases)

Code:

ecce /tmp/t # ls -l _kernel-4.12.5-gentoo.extracted/_4276.extracted/
totalt 51844
-rw-r--r-- 1 root root 19048560 17 feb 21.23 0.elf
-rw-r--r-- 1 root root  8523088 17 feb 21.23 A09B20.elf
-rw-r--r-- 1 root root   101139 17 feb 21.23 A13128
-rw-r--r-- 1 root root  6695765 17 feb 21.23 BC7D1B.xz
-rw-r--r-- 1 root root  6211696 17 feb 21.23 C3E000.elf
-rw-r--r-- 1 root root  6203504 17 feb 21.23 C40000.elf
-rw-r--r-- 1 root root  6199408 17 feb 21.23 C41000.elf
ecce /tmp/t # ls -l _kernel-4.9.76-gentoo-r1.extracted/_4076.extracted/
totalt 51364
-rw-r--r-- 1 root root 18933872 17 feb 21.23 0.elf
-rw-r--r-- 1 root root  8406992 17 feb 21.23 A0A0A0.elf
-rw-r--r-- 1 root root    97242 17 feb 21.23 A135E8
-rw-r--r-- 1 root root  6635801 17 feb 21.23 BBA757.xz
-rw-r--r-- 1 root root  6146160 17 feb 21.23 C32000.elf
-rw-r--r-- 1 root root  6137968 17 feb 21.23 C34000.elf
-rw-r--r-- 1 root root  6133872 17 feb 21.23 C35000.elf
ecce /tmp/t #


So the contents of the newly compiled kernel are structurally similar and "logically" slightly smaller than the previous one, but does not compress as well.

I don't know how to interpret that result...
Back to top
View user's profile Send private message
cadwal_se
n00b
n00b


Joined: 16 Feb 2018
Posts: 5
Location: Sweden

PostPosted: Sat Feb 17, 2018 8:47 pm    Post subject: Reply with quote

cadwal_se wrote:
Ok, I have done some more checking and there is something odd going on with ld in this case...

If I remove the -pie option in the aforementioned ld command line and run it manually, the size of the intermediate vmlinux file goes down from twice the size of piggy.o to about 1.5 times the size.

And if I then let the regular make turn that into bzImage its back to its "normal" size:

Code:

-rw-r--r-- 1 root root 5547296 17 feb 21.28 ../bzImage


Mmm...


And I checked the history now, that -pie option has been in the kernel since late March 2016 but I don't know if an ld (with a config) that triggers that code path has been present for that long in my gentoo installation.
Back to top
View user's profile Send private message
josephg
l33t
l33t


Joined: 10 Jan 2016
Posts: 783
Location: usually offline

PostPosted: Sat Mar 03, 2018 9:35 am    Post subject: Re: bzImage doubled in size Reply with quote

cadwal_se wrote:
What versions of ld (and binutils) do you have?

everything on stable: sys-devel/binutils-2.29.1-r1
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum