whats wrong with my segment descriptor

[sancho1980]

hi

my data segment is defined as follows:

Code: Select all

segdesc_t:[
  ((@text(@env("_KERNEL_SIZE"))) & %1111111111111111),
  $ffff & KERNEL_BASE,
  KERNEL_BASE >> 16,
  %10010010,
  (%1000000 | ((@text(@env("_KERNEL_SIZE"))) >> 16)),
  KERNEL_BASE >> 24
]

I also have compile time statements in my code for some debugging:

Code: Select all

#print("kernel size ", @text(@env("_KERNEL_SIZE")))
#print("anded size ", ((@text(@env("_KERNEL_SIZE"))) & %1111111111111111))
#print("shifted size ", ((@text(@env("_KERNEL_SIZE"))) >> 16))

this tells me:

Code: Select all

kernel size 66048
anded size 512
shifted size 1

so far, so good

in my kernel, i try to access a variable at 0x10300 and get

Code: Select all

00057770481e[CPU0 ] read_virtual_dword_32(): segment limit violation

i inserted some more debugging statements in bochs and this reveals that bochs thinks that the limit of my segment is actually 10200:

Code: Select all

00057770481e[CPU0 ] segment: 3
00057770481e[CPU0 ] offset: 0x10300, limit 0x10200

if i set the granularity bit of my segment to 1, all is fine, but of course, this is not a nice solution
whats wrong about how i write my segment descriptor?

[gerryg400]

Code: Select all

kernel size 66048

In hex this is 0x10200. Of course you can't access 0x10300.

[sancho1980]

hmm i feel stupid now
then my next question would be the following
i define in one of the c files used for my kernel an array

Code: Select all

static tss_t *port_accessers[NUM_PORTS] = { NULL };

the funny thing is the kernel size of kernel.bin is the same no matter if

Code: Select all

#define NUM_PORTS 1

or

Code: Select all

#define NUM_PORTS 65536

i link my kernel as follows:

ld -melf_i386 file1.o file2.o file3.o etc

and port_accessers is defined in one of the c files

any explanation?

[Combuster]

...because the output is not a flat binary?

[Selenic]

...because the output is not a flat binary?

Actually, if you place .bss at the end when linking, it doesn't even store them in a flat file (because all uninitialised memory is assumed to be zero). Also, I'm assuming it is flat, because it's called 'kernel.bin'

As for the question, there's no point storing huge runs of zeros on disk, and they're *really* common and often large (any uninitialised data, like your array there), so almost all object file formats allow you to simply specify the size and location of these blocks.

Of course, in this case, an array would be a bad idea anyway - it's probably *very* sparse. In fact, what are you using this array for? There may be better ways of doing whatever it is.

[sancho1980]

i want to use this array to keep track of which process has which port reserved.
and i am using the kernel size to set the segment limit in the gdt
so im stuck
how do i make it a flat binary
you say theres no point in storing zeroes on disk, but i want it that way
can it be done?

[Selenic]

i want to use this array to keep track of which process has which port reserved

Fair enough. I'd personally do it as a bitmap, with a per-process table, but it doesn't matter too much. Non-obvious optimisations are for when it already works (especially because you then have an idea what you need to optimise *for*)

and i am using the kernel size to set the segment limit in the gdt

Two things: firstly, you need to access memory well outside the kernel (video memory, APIC registers, etc.), hence why most kernels simply set the limit to 4Gb. Secondly, use linker symbols - by design, they'll give you the kernel size perfectly, whatever format it's in. They're in the ld manual, in Linker Scripts -> Assignments (online version from GNU site is here)