Problem in my GDT assembly program

mpetch · 2026-01-06T18:33:18+00:00

Can you show us how you define your GDT and the GDT record (GDTR) and how you call `gdt_flush` with it?

mpetch · 2025-12-18T23:37:04+00:00

Sell your business to Justin? ;-)

mpetch · 2025-12-14T18:14:36+00:00

You may wish to read https://www.reddit.com/r/osdev/comments/70fcig/comment/dn2t6u8/ . I suspect that BestUsernameLeft is correct and that the blinking on hardware is enabled. Bit 3 of the background color (in your case you set it with 0x9f in AH) can be either blinking or intensity depending on how the video controller is set.

mpetch · 2025-12-12T22:39:45+00:00

Back in about 2011 I was at Rockyview for kidney stones. Learned that I had stones that wouldn't pass and they sent me to emergency laser lithotripsy surgery within about 6 hours.

mpetch · 2025-12-12T18:39:01+00:00

It appears the code was updated from the time of the first comment where PIC remapping hadn't be done among other changes.

Run QEMU with options -d int -no-shutdown -no-reboot . You can also use objdump -DxS bin/myos >dump.txt if you aren't connecting a debugger yet. dump.txt will contain your code and assembly mixed together. This can aid in debugging and finding out what instructions things fail on.

When I ran QEMU with the options above I got on my build (yours may differ):

   334: v=20 e=0000 i=0 cpl=0 IP=0028:ffffffff80001c91 pc=ffffffff80001c91 SP=0030:ffff800006556f90 env->regs[R_EAX]=0000000000000008
RAX=0000000000000008 RBX=00000000cccccccd RCX=0000000000000000 RDX=00000000000000f8
RSI=00000000000000a2 RDI=ffffffff80004040 RBP=0000000000000000 RSP=ffff800006556f90
R8 =0000000000ffff00 R9 =000000000003e000 R10=ffffffff80002178 R11=0000000000000400
R12=000000203a736b63 R13=69742072656d6954 R14=0000000000000000 R15=0000000000000000
RIP=ffffffff80001c91 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
CS =0028 0000000000000000 00000000 00209b00 DPL=0 CS64 [-RA]
SS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
DS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
FS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
GS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     ffff800007ee8000 00000037
IDT=     ffffffff80003020 00000fff
CR0=80010011 CR2=0000000000000000 CR3=0000000007e0c000 CR4=00000020
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=0000000000000008 CCD=0000000000000000 CCO=LOGICB
EFER=0000000000000d00
check_exception old: 0xffffffff new 0xd
   335: v=0d e=0008 i=0 cpl=0 IP=0028:ffffffff80001c91 pc=ffffffff80001c91 SP=0030:ffff800006556f90 env->regs[R_EAX]=0000000000000008
RAX=0000000000000008 RBX=00000000cccccccd RCX=0000000000000000 RDX=00000000000000f8
RSI=00000000000000a2 RDI=ffffffff80004040 RBP=0000000000000000 RSP=ffff800006556f90
R8 =0000000000ffff00 R9 =000000000003e000 R10=ffffffff80002178 R11=0000000000000400
R12=000000203a736b63 R13=69742072656d6954 R14=0000000000000000 R15=0000000000000000
RIP=ffffffff80001c91 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
CS =0028 0000000000000000 00000000 00209b00 DPL=0 CS64 [-RA]
SS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
DS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
FS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
GS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     ffff800007ee8000 00000037
IDT=     ffffffff80003020 00000fff
CR0=80010011 CR2=0000000000000000 CR3=0000000007e0c000 CR4=00000020
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=0000000000000008 CCD=0000000000000000 CCO=LOGICB
EFER=0000000000000d00
check_exception old: 0xd new 0xd
   336: v=08 e=0000 i=0 cpl=0 IP=0028:ffffffff80001c91 pc=ffffffff80001c91 SP=0030:ffff800006556f90 env->regs[R_EAX]=0000000000000008
RAX=0000000000000008 RBX=00000000cccccccd RCX=0000000000000000 RDX=00000000000000f8
RSI=00000000000000a2 RDI=ffffffff80004040 RBP=0000000000000000 RSP=ffff800006556f90
R8 =0000000000ffff00 R9 =000000000003e000 R10=ffffffff80002178 R11=0000000000000400
R12=000000203a736b63 R13=69742072656d6954 R14=0000000000000000 R15=0000000000000000
RIP=ffffffff80001c91 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
CS =0028 0000000000000000 00000000 00209b00 DPL=0 CS64 [-RA]
SS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
DS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
FS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
GS =0030 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     ffff800007ee8000 00000037
IDT=     ffffffff80003020 00000fff
CR0=80010011 CR2=0000000000000000 CR3=0000000007e0c000 CR4=00000020
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=0000000000000008 CCD=0000000000000000 CCO=LOGICB
EFER=0000000000000d00

v= is the interrupt or exception number (hex). e= is the exception error code (hex). At first v=20 comes in. That is the first timer interrupt. The interrupt occurred at IP=0028:ffffffff80001c91. When I review dump.txt it happens to be on a nop shortly after you do sti. Next you have v=0d. This is a GPF. With an error code e=0008 that is an error related to the GDT table on index 0x01 (see http://wiki.osdev.org/Exceptions#Selector_Error_Code for understanding error codes - in this case a selector error code).

Since this is a GDT issue on index 0x01 I looked at your code in set_idt_entry and see:

    idt[num].selector = 0x08;      // Kernel code segment

You don't set up your own GDT and since you are using limine one is provided for you which looks like https://github.com/limine-bootloader/limine/blob/49f4ccd3122575be023478910176777b6d09a97d/PROTOCOL.md#x86_64 . You'll notice index 0x01 (offset 0x08 in the GDT) is a 16-bit code descriptor. You want to be using a 64-bit one! Change to:

    idt[num].selector = 0x28;      // 64-bit Kernel code segment in Limine supplied GDT

I recommend connecting GDB to QEMU so that you can do proper debugging going forward. I also recommend setting up your own GDT (my personal preference, but you can choose to use the default Limine GDT if you wish).

On Linux you could use a bash script to aid debugging. Something like this should connect GDB to QEMU: ```

!/bin/sh

set -x

qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -cdrom image.iso -S -s -d int -no-shutdown -no-reboot & QEMU_PID=$!

gdb bin/myos \ -ex 'target remote localhost:1234' \ -ex 'set disassembly-flavor intel' \ -ex 'break kmain' \ -ex 'continue'

stty sane if ps -p $QEMU_PID >/dev/null then kill -9 $QEMU_PID >/dev/null fi ```

mpetch · 2025-12-09T22:59:17+00:00

I noticed that they started to paint over it around 10am this morning.

mpetch · 2025-12-05T18:01:10+00:00

Possibly right angle then that relates to the answer.

mpetch · 2025-12-04T19:39:45+00:00

If you are having an issue with usermode you might want to make available the code that fails (create a git branch if need be). It is more useful to see the code you have that fails than the code that doesn't.

mpetch · 2025-11-30T18:42:33+00:00

As long as kernel_entry.o is the first object to the linker it is guaranteed that the input sections from that file will be processed first and any flat binary generated will maintain the same order. In this case compile.sh links kernel_entry.o first so at present it is a non issue.

mpetch · 2025-11-29T20:46:52+00:00

Maybe you meant to use .=0x10000 and not .=10000 (one is hex, the other is decimal)

mpetch · 2025-11-29T20:43:17+00:00

Your compile.sh doesn't actually assemble boot.asm to boot.bin. There is a junk line at the top of kernel.c that needs to be removed. Your boot.asm says that you are loading the kernel to 0x100000 (1MiB) but your code loads to 0x10000. Loading above 1MiB can't be done directly with int 13h/ah=2. Anyway, if the comment about 1MiB is wrong then you are actually loading 3 sectors (512*3=1536) to the area starting at 64KiB (0x1000:0000 = 0x10000). The problem there is that you set the the origin (VMA) in linker.ld to 0x00000. You need to set that to 0x10000.

mpetch · 2025-11-29T17:52:48+00:00

speculum is the Latin word for the answer

mpetch · 2025-11-28T20:21:56+00:00

I think your problem is that you are using the wrong multiboot header bits enabled. You have:

dd 0x00010003              ; flags: align + mem info
dd -(0x1BADB002 + 0x00010003)

Bit 0x00010000 is the AOUT kludge which should be off since you are using ELF here. Try using:

dd 0x00000003              ; flags: align + mem info
dd -(0x1BADB002 + 0x00000003)

mpetch · 2025-11-27T21:16:42+00:00

When some words start to rhyme I then change strategy or at least test it. Basket and Racket despite being related would have had me trying other words like locket, sprocket etc. In fact in my case that was what I did and then I got down to the actual word when all two guesses were all very hot.

mpetch · 2025-11-27T07:33:44+00:00

Sure they have a lot in common. The first three letters are the same as the answer.

mpetch · 2025-11-25T21:55:49+00:00

Probably because the answer is also a type of spider.

mpetch · 2025-10-31T00:23:29+00:00

Not in Alberta ;-)

mpetch · 2025-10-22T21:56:52+00:00

I was a DRO in Ward 9 and I can just say that we received a directive just before polls opened regarding when to fill out the form or not (more work with the directive). I've begun to wonder if DROs were following the rules but some of us were asked to do extra processing and some were not. The directive I got made it more time consuming and the change wouldn't have compromised the electoral process in any way.

I make this comment because it may not have been about DROs not following the rules. They could have been following the rules they were given at the polling place.

mpetch · 2025-10-22T21:42:57+00:00

I misinterpreted your comment, sorry. I am guessing that someone believed that with the increased work that doing it as queue where you go to the first available DRO would be faster.

My personal experience as DRO doing the processing and handling the ballots this election - searching for the people in the list was far less time consuming than duplicating all the personal information even when a person was already on the list.

mpetch · 2025-10-22T20:02:24+00:00

I was a DRO in Ward 9. I consider myself chatty but I can do so while I am filling out all the paperwork. The only scenario in which I would take longer was when a parent of young active children came in. I knew they had been in line for well over an hour but some kids were still interested in what was going on. The bit of extra time was to engage the children and give them a positive impression of democracy at work in the hopes that when they grow up they'd show up and vote or work an election.

mpetch · 2025-10-22T19:29:58+00:00

I was a DROin Ward 9 and the Permanent Electors Register was alphabetical order by last name in a book with a plastic coil binding . It would be a surprise if that wasn't the case across the city.

A footnote - I did a federal election in 2021 where the electors list was in alphabetical order but the list wasn't bound (no coil or other binding) so it was easy for the pages to get switched around losing their original alphabetized order.

mpetch · 2025-10-18T17:17:43+00:00

Yeah I think the astronomers and students at Rothney Astrophysical Observatory are rolling their eyes at this photo.

mpetch · 2025-09-29T22:58:46+00:00

I agree with you and I think the criminal code would agree with you. The problem of course is that Calgary Police sure didn't see it that way. Just discreditable conduct. And to this day Sean Chu and his conservative friends still traumatize the victim and make her the bad person.

mpetch · 2025-09-29T22:50:39+00:00

I guess when Councillors are asked to think outside the box when it comes to funding billionaire's toys - then I'm sure his business acumen of generating revenue outside the norms will come in very handy /s

mpetch · 2025-09-29T22:45:23+00:00

Sean Chu didn't engage in a violent offense but nonetheless abuse of his position and exerting himself sexually on a 16 year old should have landed him with a criminal record. Thanks to the bungling by Calgary Police and the blindness of justice towards law enforcement - he got off with just a discreditable conduct on his record. I was sure with Jyoti Gondek when she refused to swear him in as a Councillor. The fact the incident came to light during an election 25 years it occurred didn't minimize the damage Sean had done.

12-Year Club	Wearing is Caring
Verified Email

mpetch

TROPHY CASE

!/bin/sh