SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Some time ago I made a mistake during kernel configuration, and now I can't find the option I switched — unfortunately, I deleted the older config, so I can't do direct comparison.
The problem is: somehow I added BSS to the kernel file, which actually shouldn't be there:
„Note that the BSS segment is not stored in the kernel image because it can be synthesized at boot time by filling a block of memory with zeros.”
Have a look what size reports for two kernels I built:
Code:
root@machine/usr/src/linux-4.19.304.old/arch/x86/boot# size bzImage
size: bzImage: warning: ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .bss
text data bss dec hex filename
7971136 0 15236288 23207424 1621e00 bzImage
root@machine/usr/src/linux-6.1.72/arch/x86/boot# size bzImage
text data bss dec hex filename
5979840 0 0 5979840 5b3ec0 bzImage
Yes, that first kernel is about 2 MB bigger than it used to be (note that warning printed during sizing).
Anyone has an idea, which actually option should be switched off to get back to „normal” size? Of course from the thousand options available to search none is clearly described „add_BSS” or similar way. No „BSS” term anywhere in the config file.
root@machine/usr/src/linux-6.1.72# size vmlinux
text data bss dec hex filename
11129708 4302096 2605088 18036892 113389c vmlinux
root@machine/usr/src/linux-4.19.304# size vmlinux
text data bss dec hex filename
9020463 2461744 2723840 14206047 d8c45f vmlinux
So it seems some kind of mysterious „data” has been glued to my 4.x kernel build — but no idea how and when I did that. How to get rid of this?
Some time ago I made a mistake during kernel configuration, and now I can't find the option I switched — unfortunately, I deleted the older config, so I can't do direct comparison.
This might help.
Code:
$ /usr/src/linux/scripts/extract-ikconfig /usr/src/linux/arch/x86/boot/bzImage | head
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 6.1.70 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="gcc (GCC) 11.2.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=110200
CONFIG_CLANG_VERSION=0
CONFIG_AS_IS_GNU=y
CONFIG_AS_VERSION=23700
But I've got no problem with 6.1.x line; the problem is with 4.19.x compiled on x64 (no such issue on 32-bit machine).
Yes, in my 6.1.x configuration I have these initial lines looking exactly as yours.
I suspect it may be some kind of bug in 4.19.x line, not my mistake — introduced somewhere around 4.19.282. I'm unable to find any option, that could make the bzip2-compressed kernel file by 2 MB bigger on x64.
I don't use /proc/config.gz actually, but of course I do have my own configuration files for both kernels — there are too many differences among them to make any clear conclusion.
I was hoping anyone could know the origin of that „bss” that appeared in the kernel just out of the blue.
The BSS is always part of the kernel, it is where zero-initialized or non-initialized static variables go. The segment is shared by all of the kernel code (outside of modules, I presume), so it's hard to guess what is making it large just based on the config file. You might get more information looking at the map file for the kernel and seeing what is in the BSS segment.
I vaguely recall that the BSS doesn't take up much space in the file, rather the segment is created and filled with zeroes when the kernel is loaded. If so, it wouldn't be making the compressed kernel file any larger.
Edit: oops, I should have re-read the first post before replying. I don't think this added any useful information.
You mention that the 4.19 kernel is 2MB larger, which is the difference in the size between the text segments (i.e. where the kernel instructions are stored). Maybe this has nothing to do with the bss or data segments. Perhaps more of the code is built directly into the kernel rather than as modules?
I did look at them closely. Perhaps you are being fooled by the bad tabulation of the output in post #6. The numbers don't line up with the column headers. The 6.1.72 kernel has a larger data section than the 4.19.304 kernel in vmlinux.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
