OSDev.org

A little background. I had my bootloader loading a kernel + 3 drivers that are initialized by the kernel once loaded. 1 was i/o, one was file system, and the 3rd was for testing. The kernel was at a known location (0xF00000000) and was a coff executeable file. When I linked it, I used 0xF00000D0, since that's the offset to the .text section, and all was well. Now, since I need to store information about each file, I have a 32-byte header for the kernel, so I tried linking to 0xF00000F0 (+32, or +0x20), try to run and it crashes... finally traced down my problem to LD pre-padding the .text section with zero's! If I try to link to 0xF0000000 it pre-pends almost 4k 0's, with 0xF00000F0 it pre-pends 0x20 zero's, which completely undo's what i'm trying to accomplish, since the first instruction/variable should be at physical location 0xF00000F0, since the coff .text section starts at 0xD0, and the file header is 0x20, the physical location should be 0xf0. But for LD, it pre-pends 0x20 nulls, moving the physical location 0x20 more... 0x40 moves it again, so there is no way to get the physical location and the location asked for in LD to match. I have tried ALIGN(0) and ALIGN(1) at the start of my .text section to no avail. This is only a problem with coff executeables, and not relocatable coff's (my drivers are relocateable/dynamically linked at runtime). Are there any solutions other than using binary format (un-useable since I need the symbolic info), switch over to relocateable kernel and adding relocation code to my bootloader making it much larger than required, or writing an extra application to move all the data back to the correct position and remove all leading zero's, or writing my own linker that takes a relocateable kernel, and writes out an executeable kernel before writing it to the image. Anybody with any other ideas, I'd appreciate the insight, at this point i'm looking at writing a relocateable->executeable linker for coff files, since I could strip un-required symbolic information off at the same time.

Well, 45 reads and no responses, I'm guessing not to many people use coff format to even notice this issue . Well, I am still undecided on which way to go, add a relocator into the bootloader and just use a rellocateable coff file, write an app to simply move the data to the correct position and get rid of the padding, or write my own linker for coff file's (which I can also use to strip unrequired symbolic information at the same time).

It's a pretty intimidating block of text, and when trying to dig through I became pretty confused by your description, so I didn't quite get what is going on.

I'd suspect some default behaviour of ld / your assembler is biting you. You didn't mention which assembler you're using, if you use a linker script, ... too confused to ask the right questions, really.

Solar wrote:It's a pretty intimidating block of text, and when trying to dig through I became pretty confused by your description, so I didn't quite get what is going on.

I'd suspect some default behaviour of ld / your assembler is biting you. You didn't mention which assembler you're using, if you use a linker script, ... too confused to ask the right questions, really.

Alright, thanks for the info. I am using ld and gcc under windows (djgpp). I am using nasm for assembly, but that shouldn't make any difference since LD is what's doing the padding/linking, and it's the same if I use a.out from nasm or coff file. The problem is, that it's padding zero's to align the .text on a 4k boundary (so, a bunch of zero's before my code actually starts), even though in my linker script I only say ALIGN(1). This throws a bunch of things out of whack because it's expecting the .text section to start with the code/data and not a bunch of NOP's. This throws the alignment of all the relocations off as well. If I were to move the .text section back to where it is supposed to be, everything would work fine, it's just that ld is padding it with zero's and I don't know why or how to tell it not to. If you have questions or need any info (like my linkder script, or command line parameters), just let me know and I'd be glad to explain/simplify or give you the info you need to help me out.