<zid`>
but, it's just a copy of table 5.1 in the manual
<jafarlihi>
How do you know if you are dealing with long mode system descriptor? You get the higher half first, how do you not interpret it just as regular descriptor?
<heat>
L bit
<jafarlihi>
So you first determine that it's a system descriptor by first 4 bits of access byte? It's considered system if those bits are either 0x2, 0x9, or 0xB?
wand has quit [Remote host closed the connection]
gog has joined #osdev
<gog>
#join ##transsmut
<gog>
whoops
<j`ey>
accident or advertising?
<gog>
accident
<ddevault>
going to do a little live stream going over some details about my kernel for a few people who were curious
<jafarlihi>
Is there header I can include in LKM for getting shit like uint16_t?
wand has joined #osdev
<clever>
jafarlihi: usually, that would be stdint.h
<mrvn>
The kernel makes the GDT, why would it ever have any doubts about what each entry is?
radens has joined #osdev
<jafarlihi>
I'm working backwards with LKM, not making a kernel
srjek has quit [Ping timeout: 268 seconds]
gorgonical has joined #osdev
<radens>
In an x86 boot sector with 16 bit code, is it possible to access memory above the address (1 << 20) ?
<radens>
Alternatively, is it possible to call into the bios via eg int 0x13 from 32 bit mode?
<radens>
I'm wasting space changing between 32 bit and 16 bit mode all the time when reading from disk
<mrvn>
just use a bootloader, you are just wasting your time with dead legacy crap.
<radens>
mrvn: playing code golf is kinda fun, but also I want to build and run on OS's where it's hard to install grub into shit
dennis95 has quit [Quit: Leaving]
<heat>
> Alternatively, is it possible to call into the bios via eg int 0x13 from 32 bit mode?
<heat>
no
<heat>
you have no choice
<mrvn>
who says int 0x13 even exists?
<heat>
don't you have unreal mode?
* heat
doesn't know how that works
<radens>
Ah I forgot about that
<heat>
hmm ok that is interesting, it's basically abusing the segment caches
<heat>
the CPU itself does a similar thing in the reset vector
<heat>
cs base = 0xffff0000, ip = 0xfff0
<jafarlihi>
clever: You can't include stdint.h in the LKM
<jafarlihi>
No standard library allowed
<heat>
u16 is your linux kernel equivalent
<jafarlihi>
heat: What do I include for that? Or if nothing is required then how I make CoC happy with it?
<heat>
<linux/types.h>
<jafarlihi>
CoC doesn't give a shit about that, how do I fix it?
<heat>
CoC?
<jafarlihi>
Conquer of Completion lol
<jafarlihi>
It's a vim plugin
<heat>
i dunno
<GeDaMo>
stdint.h is a set of compiler / platform specific typedefs
<heat>
it's not allowed in the linux kernel
<heat>
partly because it was using C89, partly because who supplies it depends on the platform and toolchain
<heat>
in linux, it's the libc
mahmutov has joined #osdev
<zid`>
plus the type names are annoying so you end up defining u16 yourself anyway :P
<zid`>
defining it as uint16_t is no different to doing it as unsigned short, it's a per arch header regardless
dude12312414 has joined #osdev
jafarlihi has quit [Quit: WeeChat 3.5]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
mzxtuelkl__ has joined #osdev
mahmutov has quit [Ping timeout: 246 seconds]
mrvn has quit [Ping timeout: 246 seconds]
toluene has quit [Ping timeout: 246 seconds]
toluene has joined #osdev
mzxtuelkl_ has quit [Ping timeout: 246 seconds]
mahmutov has joined #osdev
Likorn has joined #osdev
the_lanetly_052 has quit [Ping timeout: 272 seconds]
gorgonical has quit [Quit: Client closed]
toluene has quit [Ping timeout: 246 seconds]
toluene has joined #osdev
FatAlbert has joined #osdev
<FatAlbert>
Oh, Ass dev!
gorgonical has joined #osdev
mrvn has joined #osdev
FatAlbert has left #osdev [Bye]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
blockhead has joined #osdev
nur has joined #osdev
mzxtuelkl__ has quit [Quit: Leaving]
<gorgonical>
The stuff I barely understand in this kernel really frightens me and reminds me of how much some of you guys must know. Like this head.S I'm modifying has so much "magic asm" that I don't understand very well
<bauen1>
uncommented code is nice, but magic code is just something else
<gorgonical>
I even think I could understand it, but the art of coordinating low-level asm with linker scripts to put all the stuff in the right places is very obscure to me
foudfou has quit [Ping timeout: 268 seconds]
foudfou has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
gorgonical has quit [Quit: Client closed]
foudfou has quit [Quit: Bye]
foudfou has joined #osdev
<heat>
bauen1, nice????
<bauen1>
heat: i _could_ add /s
<sbalmos>
void get_foo(void) // gets the foo
<sbalmos>
gee, thanks /s
<j`ey>
but returns void??
<gog>
foo is a void
<heat>
it returns the foo in a global variable, obviously
<sbalmos>
heat: bingo!
<gog>
lmao
<mrvn>
void get_foo(void) // set foo to void
<sbalmos>
extern struct foo_t* g_foo; // global Foo object
<heat>
gFoo for bonus hungarian notation points
<mrvn>
don't you all have: int errno; void * result;?
<sbalmos>
heat: ah, that'd be extern struct foo_t* glphFoo; // global Foo handle
<sbalmos>
mrvn: E_NOEXIST
<heat>
i'm not convinced
<heat>
can we add a GUID just so we know its unique and extendable?
<sbalmos>
sure
Likorn has quit [Quit: WeeChat 3.4.1]
<gog>
gpFoo
Likorn has joined #osdev
Likorn has quit [Client Quit]
Likorn has joined #osdev
sham1_ is now known as sham1
Likorn has quit [Client Quit]
Likorn has joined #osdev
jafarlihi has joined #osdev
<sbalmos>
ah but is it a pointer or a long pointer?
<jafarlihi>
Hey - I've got this LKM that prints GDT: https://github.com/jafarlihi/kernsec Now the issue is it reports 16th entry as this 0x40f50000000000 -- which means that it's a system segment but doesn't have one of the possible 3 long mode types, and both base and limit are 0. What the fuck is it?
<geist>
sbalmos: wouldn't that be a glp?
<sbalmos>
geist: exactly
<heat>
jafarlihi, gdts don't have 16 entries
<heat>
you need the size
<jafarlihi>
size is 127
<jafarlihi>
i loop over it all
<jafarlihi>
17th is just 0x0
<heat>
I guarantee you your GDT isn't size 127
<\Test_User>
127 meaning 128 bytes probably
<geist>
right, which is 16 entries. that lines up
<heat>
correct
<jafarlihi>
No, it means 128 entries
<jafarlihi>
wait what
<geist>
GDT/IDT/LDT length on x86 is always -1 for Reasons
<geist>
and it'sin bytes, so 127 is a 16 entry GDT
<geist>
which makes sense. there are probaby a bunch of auxillary GDT entries in linux
<geist>
jafarlihi: it's possible it's a 32bit entry, or some task thing or whatnot
<geist>
go to the source and decode it according to the manual. there's only one interpretation
<jafarlihi>
you want me to find in linux kernel source where that gets populated? lol
<geist>
the 'source' being the manual
<jafarlihi>
what manual?
<geist>
the intel or amd manual, take your pick
<geist>
the AMD manual has nicer tables for GDT types, IMO
<jafarlihi>
it doesn't fit, maybe my program is fucked
<geist>
huh?
<geist>
what doesn't fit what?
gorgonical has joined #osdev
<jafarlihi>
doesnt fit what you'd expect of descriptor
<geist>
did you decode it?
<jafarlihi>
with the lkm program yes
<jafarlihi>
maybe its buggy is what im saying
<heat>
the TSS is 2 descriptors long btw
<geist>
and what type is it?
<jafarlihi>
no type
<geist>
it has a type, it has to
<geist>
and yes, could be part of a two entry. what's in the 15th entry?
<jafarlihi>
empty
<jafarlihi>
0x0
* geist
shrugs
<geist>
well, i mean, up to you. i'd just decode it manually and see what it is. with no assumptoins about what it *should* be
<geist>
ah well i found where it's defined in the linux source if you want that
<geist>
super easy to find
<jafarlihi>
geist: tell me how you found it and where it is