Ummm...1MB kernel...!?

[stonedzealot]

The weirdest thing is happening to me. Honestly. So I'm coding along, minding my own business, generating 11k kernels, running, debugging, etc. I run into some problems, start to debug by stripping lines from the code (like unneccessary printfs and such). Now, by stripping like 8 or 9 lines from the kernel, ld now outputs a 1MB kernel.bin.

I dunno how, I'm using the same makefile to compile and write that I've always used, the .o files generated by nasm and gcc are of normal size. Honestly I'm in the dark.

Can anyone tell me how in the world code that compiles fine and links fine would just go from 11k to 1MB with the SUBTRACTION of lines?! BTW, if I put those lines back in, the kernel size goes back to normal...

[Chris Giese]

This might be caused by ".rodata" sections; found in ELF files. They contain constant data, like strings. Before GCC 3.x, there was only one ".rodata" section, but now there can be many.

If you are using a linker script (you should be), merge the .rodata sections with .text, as in this linker script:
http://my.execpc.com/~geezer/osd/code/krnl1m.ld

'objdump -h ...' is a valuable debugging tool, but it won't work on a plain binary file. Instead of making a binary file, make an ELF file, then use objcopy to convert it to binary. You can run objdump on the ELF kernel to see if everything's OK.

[Pype.Clicker]

asking ld a map of the generated file will also help.

[Neo]

asking ld a map of the generated file will also help.

how do i use a map file and and what is it actually?

[Pype.Clicker]

Code: Select all

bin/kernel.$(objextension): kern$(OSTYPE).ld $(kernelobjs) 
        @echo "linking kernel ..."
        @$(ld) -T kern$(OSTYPE).ld -o bin/kernel.$(objextension) -s -n $(kernelobjs) -Map kernel.map

the "-Map <filename>" option is how you ask a map of your binary file. the map gives you a comprehensive list of the constants, symbols etc. that were found in your objects files by the linker.

among other things, you can find

Code: Select all

Memory Configuration

Name             Origin             Length             Attributes
*default*        0x00000000 0xffffffff

Linker script and memory map

                0x00000074                . = SIZEOF_HEADERS

.text           0x00000000    0x21c00
                 0x00002000                . = 0x2000
 *fill*         0x00000000 0x100002000 00
 *(.text)
 .text          0x00002000      0x104 bin/kernel.o
                0x000020fc                farJmp
                0x000020e0                enablePaging
                0x000020f4                farCall
                0x00002000                start
 *fill*         0x00002104        0xc 00
 .text          0x000002110      0x200 bin/config.o
                0x00002232                _prepare
                0x000022eb                setBreakPoints
 .text          0x00002310      0x42b bin/control.o
...

you'll have the same for data, bss, etc.

Note that depending on how you wrote your linker script, you may end up with the 'BSS' section of your object files in the .DATA section of your final file ... this may make the linker allocate file space for uninitialized datas (which are usually just wiped to 0 at the load-time).

Make sure the BSS of every object file is collected in a dedicated .bss section and that this section is last in your script (i.e. putting initialized datas/text after the BSS can make the linker allocate file space for the BSS in some binary file formats)

Hope this helps. Feel free to post your linker script. I'll attach mine as a reference.


[attachment deleted by admin]

[Neo]

Thanks for the "map" info. I saw the attached linker script but couldn't understand the "_kerneltop= .;" part.
what is its use? does it actually point to the start of kernel code? if so then why is it at the end? sorry if the question is dumb but then I'm a beginner.
Also in some scripts i've seen
"code = .; _code = .; __code = .;" are all 3 necessary?

[Pype.Clicker]

Thanks for the "map" info. I saw the attached linker script but couldn't understand the "_kerneltop= .;" part.
what is its use? does it actually point to the start of kernel code?

No. It points to the *top* of the kernel image and is used to know the lowest address available for the heap.

the name of such labels is completely free, so it could have been "kernelend", "free_memory_start" or whatever.

Also in some scripts i've seen
"code = .; _code = .; __code = .;" are all 3 necessary?

this is likely to be a label to the start of the code. none are necessary. However, for DJGPP users, it is handy to use both 'code' and '_code' here, as it will mean the simple 'code' label can be used both in asm and in C (which prepends an underscore to every label, function name, etc.)