OSDev.org

I am having an issue getting a linker symbol to be placed at the end of my kernel when debug information is added.
I have my own linker script with a symbol placed at its end to mark the end of the kernel and the idea is to cat on a tar file for use as a initrd.
Problem is any time i do a debug build the debug information is placed after the end of kernel symbol and that then screws up the offset to the initrd.

I have tried specifying the sections for debug information in the linker script it self but that seems to mess up an offset gdb uses and it does not load debugging symbols properly.
So i find myself at a bit of a loss as to how i can work around this issue.

i have used a hex editor to conform the position of the initrd so i know the symbol when i get its address at run time is incorrect and can see the debug information after the offset of the end of kernel symbol.

Does anyone know of a way to tell ld where to put debug information without messing up the offset for gdb.
Or maybe have some advice as what direction to look next for a possible solution.

Regards Xain Faith

Is there some reason you can't load the initrd as a separate file?

Have you tried stripping the kernel before concatenating the files? You only need debug symbols in the binary you give to gdb.

I'm afraid this is a known GNU/ld issue, which regularly pops up on this forum. I first run into this problem three years ago, and haven't found any solution as of yet.

I'd recommend altering your boot loader to load the kernel and the initrd separately, then pass the address of the initrd to your kernel. Or alternatively you could do what I do, I include the kernel itself in the initrd. Assuming your kernel is the first file in the initrd, you can get the address by using not bss_end, but text_start label minus 512.
This way you don't have to care about how big the debug info section is, because you can jump over your entire kernel using the tar meta info. Downside you'll have to be careful about allocating the bss, so that it won't overlap with the second file (I solve this by mapping the kernel at higher half, and mapping known-to-be-free pages for the bss).

Cheers,
bzt