...so I write some Assembly code for a new Kernel, compile it to binary with NASM and all is well. Its approx. 300 bytes in size.
Next, I decide to write some C code. I can only compile that to a COFF object format, so I do. I have to switch NASM to compile to COFF (not the Win32 type, because the DJGPP linker doesn't like that).
I go and link it, and everything looks fine, until I look at the kernel size... 8k!!!
Where the hell did this bloat come from?!!?
The C code was a "main" function that put a value in a variable (just to see if the jump from Assembly to C worked).
Its strange how the Kernel went from 300 bytes to 8k.
The C code, at most, was 20 bytes.
I disassembled the file, and the whole thing was filled with white space, except the 300 bytes right in the middle.
Apparently all the white space is from the .data and .bss sections, which I left completely empty (except for that one variable).
Is there any way to put all this together without the unneeded bloat?
COFF Kernel size... :-(
RE:COFF Kernel size... :-(
How are you compiling?
Show us your compile-time (gcc, ld or ldscript options.
Hmm... strange... your .bss is already zeroed and accounted for?
Show us your compile-time (gcc, ld or ldscript options.
Hmm... strange... your .bss is already zeroed and accounted for?
RE:COFF Kernel size... :-(
The .bss section isn't included in the final compilation; that's the purpose of the .bss section
And .data should only be as big as the variables you've defined, so these shouldn't really be your problem.
GCC, no doubt, puts extra sections into your objects (nasm will, as well... I believe it puts in a .label section which contains "assembled by the netwide assembler") which'll take up space. There might be GCC command line options to get rid of any superflous sections (again, I believe nasm has an option for this). Alternately, you might be able to use a ld linker script to remove these sections, if they are, indeed, your problem.
I'd check GCC's assembly output, gcc -S file.c, and check file.s to see exactly what GCC is producing.
Jeff
And .data should only be as big as the variables you've defined, so these shouldn't really be your problem.
GCC, no doubt, puts extra sections into your objects (nasm will, as well... I believe it puts in a .label section which contains "assembled by the netwide assembler") which'll take up space. There might be GCC command line options to get rid of any superflous sections (again, I believe nasm has an option for this). Alternately, you might be able to use a ld linker script to remove these sections, if they are, indeed, your problem.
I'd check GCC's assembly output, gcc -S file.c, and check file.s to see exactly what GCC is producing.
Jeff
RE:COFF Kernel size... :-(
Use "objdump -h foo" to check the section headers. See if the assembler or compiler is adding unknown sections e.g. debug or .comment sections.
The MinGW linker has an option (--file-alignment) to set the alignment of sections in the file. Alas, the DJGPP linker doesn't support this option, and it doesn't look like writing a linker script will help.
Maybe use the -s option to strip out all symbols, too.
The MinGW linker has an option (--file-alignment) to set the alignment of sections in the file. Alas, the DJGPP linker doesn't support this option, and it doesn't look like writing a linker script will help.
Maybe use the -s option to strip out all symbols, too.