I can suggest one messy workaround - how about compiling with -m32 and then using objcopy to create a 64 bit elf binary?
Cheers,
Adam
GRUB2 Woes - Fixed (or not)
Hi Adam,
Wow. Messy it may be, but it works!
I've modified my makefile so that during the compilation process it runs a "objcopy -O elf64-x86-64 $@" on every elf32 output by g++, and then it links it all as per normal.
ld complains about several things, but it still links and the code still works
So, based on that, it looks like I can now write my 64-bit paging code in C++ and have all of my 32 / 64 code in the one file. Awesome!
I am in your debt.
Many thanks,
Lee
Wow. Messy it may be, but it works!
I've modified my makefile so that during the compilation process it runs a "objcopy -O elf64-x86-64 $@" on every elf32 output by g++, and then it links it all as per normal.
ld complains about several things, but it still links and the code still works
So, based on that, it looks like I can now write my 64-bit paging code in C++ and have all of my 32 / 64 code in the one file. Awesome!
I am in your debt.
Many thanks,
Lee
Ahhh, it couldn't be that simple, could it?
If I use my old linker script (which I stole from a tutorial and modified very slightly), GRUB2 fails to read the binary. The reason I wish to use this script is because it defines a symbol at the end, and I use this to determine where the kernel ends in memory--the address of that symbol is the end of the kernel.
I've noticed that elf files seem to have an _end symbol predefined, so I've tried taking the address of that at runtime, but if it is indeed the end of the kernel, I'm getting bogus information somehow, since it's telling me the kernel is ending at 0x601D88, which can't be right.
Interestingly, after I've linked the files objdump can't read it at all.
Any thoughts?
Cheers,
Lee
If I use my old linker script (which I stole from a tutorial and modified very slightly), GRUB2 fails to read the binary. The reason I wish to use this script is because it defines a symbol at the end, and I use this to determine where the kernel ends in memory--the address of that symbol is the end of the kernel.
I've noticed that elf files seem to have an _end symbol predefined, so I've tried taking the address of that at runtime, but if it is indeed the end of the kernel, I'm getting bogus information somehow, since it's telling me the kernel is ending at 0x601D88, which can't be right.
Interestingly, after I've linked the files objdump can't read it at all.
Any thoughts?
Cheers,
Lee
Well, I'd given up and decided to do what someone in a thread here suggested to someone else. I decided to write a 32-bit kernel stub which gets passed the 64-bit kernel as a module, via GRUB. The stub will setup long mode and jump into the 64-bit kernel.
To this end, I started writing something to read the 64-bit ELF files and load them into memory. While doing this, I discovered the strange address for the _end symbol IS accurate. How strange. This means some of my kernel ended up at roughly the 6mb mark! I suppose this is what you get when you allow ld to do what it wants
The other strange thing is when I use the linker script, ld is outputting less sections. It seems to only have a code section.
Oh well, I'm happy regardless..
Thanks to everyone who posted for your assistance
Cheers,
Lee
To this end, I started writing something to read the 64-bit ELF files and load them into memory. While doing this, I discovered the strange address for the _end symbol IS accurate. How strange. This means some of my kernel ended up at roughly the 6mb mark! I suppose this is what you get when you allow ld to do what it wants
The other strange thing is when I use the linker script, ld is outputting less sections. It seems to only have a code section.
Oh well, I'm happy regardless..
Thanks to everyone who posted for your assistance
Cheers,
Lee
If you are good at amd 64 abi, help to kill this bug off.
http://sourceware.org/bugzilla/show_bug.cgi?id=5059
http://sourceware.org/bugzilla/show_bug.cgi?id=5059