HigherHalf with GDT Alignment issues

[elaverick]

When trying to compile the HigherHalf with GDT example, my copy of GCC reports

Code: Select all

c:/Source Code/Kernel/FidgetOSHH/Kernel/mem/paging.c:15: warning: alignment of `kernelpagedir' is greater than maximum object file alignment. Using 16

(and the same with lowpagetable)
When I run the kernel I get a PANIC exception when this code is run.
I assume this is something to do with warning I get in compilation. My code is exactly as is shown in the tutorial so my question is how do I resolve the warning?

[Pype.Clicker]

what version of GCC do you use ?

c:/Source Code/Kernel/FidgetOSHH/Kernel/mem/paging.c:15: warning: alignment of `kernelpagedir' is greater than maximum object file alignment. Using 16

seems like you have something like "align 4096" or something while the compiler prefer something at max "align 16", resulting in non-properly-aligned page directories, chaos, madness, and end-of-the-universe

Of course, that barely helps you ... try using a more recent version of your compiler or another version (e.g. switch from djgpp/mingw to cygwin).

[elaverick]

It's 3.1 from the DJGPP 2.03 release. I've just tried updating to 3.32 from the DJGPP 2.04 Alpha2 build but that doesn't seemed to have helped.
Am I going to have to go through the pain of setting up a new Build Environment then

[Pype.Clicker]

i fear so, indeed ... or you'll have to use some other means to declare your page-aligned tables ...

I'd suggest a linker script statement (the linker shouldn't worry about you stating there will be padding so that your next symbol comes at some aligned address, especially in .bss section), or align/resb magic in an assembler file...

[elaverick]

Tried switching from DJGPP to Cygwin but to no avail. The Cygwin version of GCC reports itself to be 3.4.4 but it too complains that 4096 is greater than its prepared to allow me and reverts back to 16.

So how to I go from:

Code: Select all

unsigned long kernelpagedir[1024] __attribute__ ((aligned (4096)));
unsigned long lowpagetable[1024] __attribute__ ((aligned (4096)));

In C to placing that in a linker script... I've not really had a lot of cause to deal with Linker scripts before as I'm more used to the happy clappy world of Visual Studio where it's all done for you with lots of hand holding.

= EDIT =

Am I on the right lines with this?

Code: Select all

OUTPUT_FORMAT("elf32-i386")
ENTRY(start)

SECTIONS
{
        . = 0x100000;

        .setup :
        {
                *(.setup)
        }

        . += 0xC0000000;

        .text : AT(ADDR(.text) - 0xC0000000)
        {
                *(.text)
        }

        .data ALIGN (4096) : AT(ADDR(.data) - 0xC0000000)
        {
                *(.data)
                *(.rodata*)
                kernelpagedir = ALIGN(4096)
                lowpagetable = ALIGN(4096)
        }

        .bss ALIGN (4096) : AT(ADDR(.bss) - 0xC0000000)
        {
                *(COMMON*)
                *(.bss*)
        }
}

Or am I confusing definitions of variables between code and linker scripts?

[elaverick]

Ok I've tried a couple of variations on that script but the best result I can get is an Error 28 : Selected Item Cannot Fit in Memory.

Can anyone give me a clue as to what I'm doing wrong?

[elaverick]

Right I've finally got a solution for the problem. Turns out it was PEBCAK all along...

Probably everyone else on the forum has already figured this out, but just in case someone comes along who's new to OS dev and also from the mollycoddled Windows/Visual Studio route of developing... The GCC compiler that ships with Cygwin and DJGPP does NOT natively support ELF output.

My Cygwin build had been producing some other form of intermediate code which the linker was then quite happily converting into an ELF executable but the limits of that format meant that I couldn't align variables past 16 bytes. The ELF format can however align at 4kb.

So the solution is to go and build a copy GCC (and Bintools so that you can do that) which supports the i586-elf target.

I feel quite silly to have spent so long on this trivial problem, but I'm chuffed to bits that it's fixed now. Hope this helps someone else further down the line.

[Candy]

Probably everyone else on the forum has already figured this out, but just in case someone comes along who's new to OS dev and also from the mollycoddled Windows/Visual Studio route of developing... The GCC compiler that ships with Cygwin and DJGPP does NOT natively support ELF output.

My Cygwin build had been producing some other form of intermediate code which the linker was then quite happily converting into an ELF executable but the limits of that format meant that I couldn't align variables past 16 bytes. The ELF format can however align at 4kb.

So the solution is to go and build a copy GCC (and Bintools so that you can do that) which supports the i586-elf target.

I feel quite silly to have spent so long on this trivial problem, but I'm chuffed to bits that it's fixed now. Hope this helps someone else further down the line.

That is one of the reasons why the OS FAQ strongly recommends everybody (even those on unix with an ELF compiler) to build a crosscompiler for their own system that doesn't include any OS-specific hacks for your work-OS. Say, PE or COFF support.