Page 1 of 2

Segment Limit of 0xFFFFFFFF

Posted: Fri Sep 04, 2009 12:47 am
by oib111
In a GDT entry, bit 55 is the granularity bit. If it's set that means you multiply the segment limit by 4096 (or 1000h). So if you have a segment limit of 0xFFFFF and you have the granularity bit set, you'll really only end up with a segment limit of 0xFFFFF000. So I'm wondering, how is it possible to get a segment limit of 0xFFFFFFFF?

Re: Segment Limit of 0xFFFFFFFF

Posted: Fri Sep 04, 2009 1:04 am
by Combuster
Because it doesn't work that way.

The limit contains the last accessible byte, and with the G bit set, the last accessible page. If you have a limit of 0, the segment is 1 byte in size (since you can access byte 0), with granularity enabled, you can access everything up to page 0, which is 0x000 - 0xfff, giving you 4096 bytes.

So if you set a limit of 0xFFFFF with page granularity, you define the last accessible page as 0xfffff000-0xffffffff, and you can access anything from 0x00000000 to 0xffffffff.

Remember, limit fields are sizes - 1. You'll see the same thing happening in the GDT/IDT register

Re: Segment Limit of 0xFFFFFFFF

Posted: Fri Sep 04, 2009 1:12 am
by oib111
Oh thanks. It all makes sense now! Also...is there a way I can configure Visual Studio to use NASM instead of MASM?

Re: Segment Limit of 0xFFFFFFFF

Posted: Fri Sep 04, 2009 8:30 am
by Creature
oib111 wrote:Oh thanks. It all makes sense now! Also...is there a way I can configure Visual Studio to use NASM instead of MASM?
Try using custom build rules and tools, they are a pain to set up if it's your first time, but they're pretty rewarding if they're set up correctly. If it's too hard, you can always take a look at the YASM assembler, which has support for GAS and NASM syntax whilst having a Visual Studio build rule plug-in (you can just drop it in VC++ and tell VC++ to use YASM for Assembly files).

Re: Segment Limit of 0xFFFFFFFF

Posted: Fri Sep 04, 2009 12:18 pm
by oib111
Yeah I was trying to set it up with custom build rules before but I had no idea what I was doing and I couldn't find any tutorials out there on it. I'll take a look at YASM, thanks :)

Re: Segment Limit of 0xFFFFFFFF

Posted: Fri Sep 04, 2009 12:59 pm
by neon
Hello,

Here is what I do to mix NASM with MSVC:

1. Add the nasm asm file to the project
2. Right click the asm file in the MSVC project, select Properties
3. Go to Configuration Properties->General, set Tool to Custom Build Tool
4. Go to Custom Build Step->General and set Command Line to either the command line to build the NASM file, or point it to a Batch script that builds it.
5. In that same location, set Outputs to the OBJ file that your command line should output.
6. Hit Apply.

As long as the NASM command line is set to build the NASM files as 32 bit OBJ files [there are ways you can mix 16 bit code in it as well though], MSVC should automatically assemble and link the generated OBJ file to the rest of the project.

Re: Segment Limit of 0xFFFFFFFF

Posted: Fri Sep 04, 2009 1:01 pm
by oib111
Oh cool thanks! :D

EDIT:

Having a slight problem. The custom build step worked except I'm getting a bunch of unresolved externals in some functions:
gdt.obj : error LNK2019: unresolved external symbol _gdt_flush referenced in function _gdt_install
idt.obj : error LNK2019: unresolved external symbol _idt_load referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr31 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr30 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr29 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr28 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr27 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr26 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr25 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr24 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr23 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr22 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr21 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr20 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr19 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr18 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr17 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr16 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr15 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr14 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr13 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr12 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr11 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr10 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr9 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr8 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr7 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr6 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr5 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr4 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr3 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr2 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr1 referenced in function _install_idt
idt.obj : error LNK2019: unresolved external symbol _isr0 referenced in function _install_idt
E:\OIBKRNL.EXE : fatal error LNK1120: 34 unresolved externals
It's a bit odd because system.h has the prototypes for all the ISRs, gdt_flush, and idt_load. idt.c and gdt.c include system.h so they shouldn't be getting those errors...should they?

Re: Segment Limit of 0xFFFFFFFF

Posted: Fri Sep 04, 2009 6:26 pm
by pcmattman

Code: Select all

_isr5
Looks like underscores are being added to all your symbols... In your assembly file you'll need to name all your ISRs "_isr<n>" rather than "isr<n>".

Re: Segment Limit of 0xFFFFFFFF

Posted: Fri Sep 04, 2009 6:30 pm
by neon
Also make sure of the following in your assembly file:

1. It has bits 32 and section .text at the top. I am personally not sure if these are required though;
2. Any function or varable that you want exported must be global. ie: global _label. This will put the symbol, _label, in the OBJ file for the linker to find.

Re: Segment Limit of 0xFFFFFFFF

Posted: Fri Sep 04, 2009 6:49 pm
by oib111
I'm already using underscores and the global keyword. I'm using [BITS 32], but not [SECTION .text], I'll see if adding the latter works :)

EDIT:

Adding [SECTION .text] didn't help. But I just noticed this error:

Code: Select all

LINK : error LNK2001: unresolved external symbol _start
How can I get the entry point of my kernel to be the start function in kernel.asm (I set the entry point option in Linker>Advanced to start....but that's not working?)

Re: Segment Limit of 0xFFFFFFFF

Posted: Fri Sep 04, 2009 7:09 pm
by zman97211
LINK : error LNK2001: unresolved external symbol _start
I had this same problem, the example sources I was using didn't have the _start symbol in a section.
Adding [SECTION .text] didn't help.
Don't use brackets. I didn't. (I must admit I'm not sure if that is really a problem).

I was still able to run my kernel, since the very first byte loaded at 0x100000 was really the very first byte after _start:, and ld just assumed and set my entry point to 0x100000. After I added section .text right before _start, the warning went away.

I'm actually curious why my _start code was even present in that kernel since it wasn't defined in the link script to be copied anywhere in the output... Anyone have an idea on this? Is there a .leftovers section? :wink:

Steve

Re: Segment Limit of 0xFFFFFFFF

Posted: Fri Sep 04, 2009 7:32 pm
by neon

Code: Select all

LINK : error LNK2001: unresolved external symbol _start
Do you have a global label with the exact name "_start"? Are you sure that your main project is linking the produced OBJ file?

I personally would just set a C entry point. If you need some setup that can only be done in assembly language, call the asm function from the C entry point.

Re: Segment Limit of 0xFFFFFFFF

Posted: Sat Sep 05, 2009 12:07 am
by oib111
I fixed all the unresolved externals except for:

Code: Select all

LINK : error LNK2001: unresolved external symbol _start
Not sure why this one persists. I think I'll just have a C function that will then call start (nevermind I just get an unresolved external on that. Oh well lol.

Re: Segment Limit of 0xFFFFFFFF

Posted: Sat Sep 05, 2009 3:13 am
by Creature
oib111 wrote:I fixed all the unresolved externals except for:

Code: Select all

LINK : error LNK2001: unresolved external symbol _start
Not sure why this one persists. I think I'll just have a C function that will then call start (nevermind I just get an unresolved external on that. Oh well lol.
If you've set up everything correctly, this error is usually generated when you forgot to add -nostdlib and companions. The linker will look for a default entry point.

Are you sure you have the following in your compiler arguments:

Code: Select all

-nostdlib -nostartfiles -nodefaultlibs -nostdinc --no-builtin
If you're using C, you might also need to add "-ffreestanding" and if using C++, you might also need

Code: Select all

--no-rtti --no-stack-protector --no-exceptions
I'm not sure if the stack protector should also be disabled in C or if it's already disabled by default, etc.

Re: Segment Limit of 0xFFFFFFFF

Posted: Sat Sep 05, 2009 11:42 am
by oib111
Aren't those GCC options? I'm using Visual Studio?