Page 1 of 1
whats wrong with my segment descriptor
Posted: Mon Jun 07, 2010 4:09 pm
by 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?
Re: whats wrong with my segment descriptor
Posted: Mon Jun 07, 2010 8:04 pm
by gerryg400
In hex this is 0x10200. Of course you can't access 0x10300.
Re: whats wrong with my segment descriptor
Posted: Tue Jun 08, 2010 2:09 pm
by 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
or
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?
Re: whats wrong with my segment descriptor
Posted: Tue Jun 08, 2010 2:38 pm
by Combuster
...because the output is not a flat binary?
Re: whats wrong with my segment descriptor
Posted: Tue Jun 08, 2010 2:47 pm
by Selenic
Combuster wrote:...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.
Re: whats wrong with my segment descriptor
Posted: Tue Jun 08, 2010 3:32 pm
by 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?
Re: whats wrong with my segment descriptor
Posted: Tue Jun 08, 2010 4:08 pm
by Selenic
sancho1980 wrote: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*)
sancho1980 wrote: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)