segmentation fault

[yemista]

Well the code is loaded to 0x00100000(i moved it back a byte but same problem), so ds and cs both have a base of 0x00100000. I dont know why there is not a 4G limit. If what you mean is paging is not on, thats what I want for now until Im at that point. Also, show ds and show-mem do not appear to be valid bochs commads.

[yemista]

oh yea, i also noticed this. I dont know why it switches back to real mode.

00000790162: switched from 'real mode' to 'protected mode'
00000829210: switched from 'protected mode' to 'real mode'
00171041715: switched from 'real mode' to 'protected mode'
(0).[173019887] [0x00100678] 0008:00000678 (unk. ctxt): nop ; 90

[yemista]

ok I have a slight clue towards whats going on. The instructions that set the isr addresses within the idt are not working at all. They just dont seem to do anything. Heres another bochs dump, including the disassembled instructions, and the contents of the memory location after the move, which is not changed as it should be.

Code: Select all

<bochs:20> r
eax: 0x00000000 0
ecx: 0x00000002 2
edx: 0x00000000 0
ebx: 0x00000010 16
esp: 0x0000ffd6 65494
ebp: 0x00000000 0
esi: 0x000e7c17 949271
edi: 0x0000ffac 65452
eip: 0x00000236
eflags 0x00000046
id vip vif ac vm rf nt IOPL=0 of df if tf sf ZF af PF cf
<bochs:21> s
Next at t=171041726
(0) [0x0010023b] 0008:0000023b (unk. ctxt): mov word ptr ds:0x86, ax  ; 66a386000000
<bochs:22> r
eax: 0x00000014 20
ecx: 0x00000002 2
edx: 0x00000000 0
ebx: 0x00000010 16
esp: 0x0000ffd6 65494
ebp: 0x00000000 0
esi: 0x000e7c17 949271
edi: 0x0000ffac 65452
eip: 0x0000023b
eflags 0x00000046
id vip vif ac vm rf nt IOPL=0 of df if tf sf ZF af PF cf
<bochs:23> s
Next at t=171041727
(0) [0x00100241] 0008:00000241 (unk. ctxt): shr eax, 0x10             ; c1e810
<bochs:24> x 0x00100086
[bochs]:
0x00100086 <bogus+       0>:	0x00080000
<bochs:25> x 0x00080000
[bochs]:
0x00080000 <bogus+       0>:	0x00000000
<bochs:26> 

[stlw]

Also, show ds and show-mem do not appear to be valid bochs commads

Only if you using very old version of Bochs.
Try:

> help show
> show "DS"
> trace-mem on
> trace-mem off

Pay attention on quotes. BTW, never told you about "show-mem".

Stanislav

[yemista]

ok those commands worked. trace-mem itself does not, and show ds does not, but show "DS" does.

here is my ds before the lidt instruction
here is another bochs dump, this time showing ds before and after lidt, and it also shows the results of trace-mem which at least to me indicate that memory is being written as it should, but it just wont stick, indicating that maybe there is something wrong in bochs. The instructions execute properly, they just do not seem to be copying any actual memory

Code: Select all

[CPU0 WR]: LIN 0x00000176 PHY 0x00000176 (len=2, pl=0): 0x0010
[CPU0 WR]: LIN 0x0000017c PHY 0x0000017c (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x0000017e PHY 0x0000017e (len=2, pl=0): 0x0012
[CPU0 WR]: LIN 0x00000184 PHY 0x00000184 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x00000186 PHY 0x00000186 (len=2, pl=0): 0x0014
[CPU0 WR]: LIN 0x0000018c PHY 0x0000018c (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x0000018e PHY 0x0000018e (len=2, pl=0): 0x0016
[CPU0 WR]: LIN 0x00000194 PHY 0x00000194 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x00000196 PHY 0x00000196 (len=2, pl=0): 0x0018
[CPU0 WR]: LIN 0x0000019c PHY 0x0000019c (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x0000019e PHY 0x0000019e (len=2, pl=0): 0x001A
[CPU0 WR]: LIN 0x000001a4 PHY 0x000001a4 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000001a6 PHY 0x000001a6 (len=2, pl=0): 0x001C
[CPU0 WR]: LIN 0x000001ac PHY 0x000001ac (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000001ae PHY 0x000001ae (len=2, pl=0): 0x001E
[CPU0 WR]: LIN 0x000001b4 PHY 0x000001b4 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000001b6 PHY 0x000001b6 (len=2, pl=0): 0x0020
[CPU0 WR]: LIN 0x000001bc PHY 0x000001bc (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000001be PHY 0x000001be (len=2, pl=0): 0x0022
[CPU0 WR]: LIN 0x000001c4 PHY 0x000001c4 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000001c6 PHY 0x000001c6 (len=2, pl=0): 0x0024
[CPU0 WR]: LIN 0x000001cc PHY 0x000001cc (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000001ce PHY 0x000001ce (len=2, pl=0): 0x0026
[CPU0 WR]: LIN 0x000001d4 PHY 0x000001d4 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000001d6 PHY 0x000001d6 (len=2, pl=0): 0x0028
[CPU0 WR]: LIN 0x000001dc PHY 0x000001dc (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000001de PHY 0x000001de (len=2, pl=0): 0x002A
[CPU0 WR]: LIN 0x000001e4 PHY 0x000001e4 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000001e6 PHY 0x000001e6 (len=2, pl=0): 0x002C
[CPU0 WR]: LIN 0x000001ec PHY 0x000001ec (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000001ee PHY 0x000001ee (len=2, pl=0): 0x002E
[CPU0 WR]: LIN 0x000001f4 PHY 0x000001f4 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000001f6 PHY 0x000001f6 (len=2, pl=0): 0x0030
[CPU0 WR]: LIN 0x000001fc PHY 0x000001fc (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000001fe PHY 0x000001fe (len=2, pl=0): 0x0032
[CPU0 WR]: LIN 0x00000204 PHY 0x00000204 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x00000206 PHY 0x00000206 (len=2, pl=0): 0x0034
[CPU0 WR]: LIN 0x0000020c PHY 0x0000020c (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x0000020e PHY 0x0000020e (len=2, pl=0): 0x0036
[CPU0 WR]: LIN 0x00000214 PHY 0x00000214 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x00000216 PHY 0x00000216 (len=2, pl=0): 0x0038
[CPU0 WR]: LIN 0x0000021c PHY 0x0000021c (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x0000021e PHY 0x0000021e (len=2, pl=0): 0x003A
[CPU0 WR]: LIN 0x00000224 PHY 0x00000224 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x00000226 PHY 0x00000226 (len=2, pl=0): 0x003C
[CPU0 WR]: LIN 0x0000022c PHY 0x0000022c (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x0000022e PHY 0x0000022e (len=2, pl=0): 0x003E
[CPU0 WR]: LIN 0x00000234 PHY 0x00000234 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x00000236 PHY 0x00000236 (len=2, pl=0): 0x0040
[CPU0 WR]: LIN 0x0000023c PHY 0x0000023c (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x0000023e PHY 0x0000023e (len=2, pl=0): 0x0042
[CPU0 WR]: LIN 0x00000244 PHY 0x00000244 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x00000246 PHY 0x00000246 (len=2, pl=0): 0x0044
[CPU0 WR]: LIN 0x0000024c PHY 0x0000024c (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x0000024e PHY 0x0000024e (len=2, pl=0): 0x0046
[CPU0 WR]: LIN 0x00000254 PHY 0x00000254 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x00000256 PHY 0x00000256 (len=2, pl=0): 0x0048
[CPU0 WR]: LIN 0x0000025c PHY 0x0000025c (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x0000025e PHY 0x0000025e (len=2, pl=0): 0x004A
[CPU0 WR]: LIN 0x00000264 PHY 0x00000264 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x00000266 PHY 0x00000266 (len=2, pl=0): 0x004C
[CPU0 WR]: LIN 0x0000026c PHY 0x0000026c (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x0000026e PHY 0x0000026e (len=2, pl=0): 0x004E
[CPU0 WR]: LIN 0x00000274 PHY 0x00000274 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x00000276 PHY 0x00000276 (len=2, pl=0): 0x0050
[CPU0 WR]: LIN 0x0000027c PHY 0x0000027c (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x0000027e PHY 0x0000027e (len=2, pl=0): 0x0052
[CPU0 WR]: LIN 0x00000284 PHY 0x00000284 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x00000286 PHY 0x00000286 (len=2, pl=0): 0x0054
[CPU0 WR]: LIN 0x0000028c PHY 0x0000028c (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x0000028e PHY 0x0000028e (len=2, pl=0): 0x0056
[CPU0 WR]: LIN 0x00000294 PHY 0x00000294 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x00000296 PHY 0x00000296 (len=2, pl=0): 0x0058
[CPU0 WR]: LIN 0x0000029c PHY 0x0000029c (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x0000029e PHY 0x0000029e (len=2, pl=0): 0x005A
[CPU0 WR]: LIN 0x000002a4 PHY 0x000002a4 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000002a6 PHY 0x000002a6 (len=2, pl=0): 0x005C
[CPU0 WR]: LIN 0x000002ac PHY 0x000002ac (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000002ae PHY 0x000002ae (len=2, pl=0): 0x005E
[CPU0 WR]: LIN 0x000002b4 PHY 0x000002b4 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000002b6 PHY 0x000002b6 (len=2, pl=0): 0x0060
[CPU0 WR]: LIN 0x000002bc PHY 0x000002bc (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000002be PHY 0x000002be (len=2, pl=0): 0x0062
[CPU0 WR]: LIN 0x000002c4 PHY 0x000002c4 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000002c6 PHY 0x000002c6 (len=2, pl=0): 0x0064
[CPU0 WR]: LIN 0x000002cc PHY 0x000002cc (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000002ce PHY 0x000002ce (len=2, pl=0): 0x0066
[CPU0 WR]: LIN 0x000002d4 PHY 0x000002d4 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000002d6 PHY 0x000002d6 (len=2, pl=0): 0x0068
[CPU0 WR]: LIN 0x000002dc PHY 0x000002dc (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000002de PHY 0x000002de (len=2, pl=0): 0x006A
[CPU0 WR]: LIN 0x000002e4 PHY 0x000002e4 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000002e6 PHY 0x000002e6 (len=2, pl=0): 0x006C
[CPU0 WR]: LIN 0x000002ec PHY 0x000002ec (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000002ee PHY 0x000002ee (len=2, pl=0): 0x006E
[CPU0 WR]: LIN 0x000002f4 PHY 0x000002f4 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000002f6 PHY 0x000002f6 (len=2, pl=0): 0x0070
[CPU0 WR]: LIN 0x000002fc PHY 0x000002fc (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x000002fe PHY 0x000002fe (len=2, pl=0): 0x0072
[CPU0 WR]: LIN 0x00000304 PHY 0x00000304 (len=2, pl=0): 0x0000
[CPU0 WR]: LIN 0x00000107 PHY 0x00000107 (len=4, pl=0): 0x00000076
[CPU0 WR]: LIN 0x00000105 PHY 0x00000105 (len=2, pl=0): 0x0198
(0) Breakpoint 2, 0x00100612 in ?? ()
Next at t=171041923
(0) [0x00100612] 0008:00000612 (unk. ctxt): lidt ds:0x5               ; 0f011d05000000
<bochs:12> show "DS"
show param name: <DS>
DS = 
  selector = 0x10 (hex number)
  base = 0x100 (hex number)
  limit = 0xffff (hex number)
  limit_scaled = 0xffff (hex number)
  ar_byte = 0x93 (hex number)
  granularity = false (boolean)
  d_b = false (boolean)
  avl = false (boolean)
<bochs:13> s
[CPU0 RD]: LIN 0x00000107 PHY 0x00000107 (len=4, pl=0): 0x00000076
[CPU0 RD]: LIN 0x00000105 PHY 0x00000105 (len=2, pl=0): 0x0198
Next at t=171041924
(0) [0x00100619] 0008:00000619 (unk. ctxt): mov al, 0x11              ; b011
<bochs:14> show "DS"
show param name: <DS>
DS = 
  selector = 0x10 (hex number)
  base = 0x100 (hex number)
  limit = 0xffff (hex number)
  limit_scaled = 0xffff (hex number)
  ar_byte = 0x93 (hex number)
  granularity = false (boolean)
  d_b = false (boolean)
  avl = false (boolean)

Im probably wrong, but at this point all i can think is bochs is screwing up. My ds segment allows for writing.

[ru2aqare]

Code: Select all

[CPU0 WR]: LIN 0x00000107 PHY 0x00000107 (len=4, pl=0): 0x00000076
[CPU0 WR]: LIN 0x00000105 PHY 0x00000105 (len=2, pl=0): 0x0198

...

DS = 
  base = 0x100 (hex number)

I noticed that your data segment base address is 0x100. If I remember correctly, the base address in the IDTR is a physical addres, and you write a virtual address there. So the processor may be looking in the wrong place.

[stlw]

Code: Select all

[CPU0 WR]: LIN 0x00000107 PHY 0x00000107 (len=4, pl=0): 0x00000076
[CPU0 WR]: LIN 0x00000105 PHY 0x00000105 (len=2, pl=0): 0x0198

...

DS = 
  base = 0x100 (hex number)

I noticed that your data segment base address is 0x100. If I remember correctly, the base address in the IDTR is a physical addres, and you write a virtual address there. So the processor may be looking in the wrong place.

The base in the IDTR is not physical but linear address.
But anyway - DS.BASE is 0x100 instead of 0x00100000 and limit is 0xffff only.
I would guess you loaded your DS in real mode and not in protected mode - so intead of reading descriptor from GDT it just assigned default real mode values,
like base = selector << 4.

This is also causes all the rest to be wrong, instead of reading from descriptor table memory you read from 0x105-0x107 and I am sure data has not too much meaning there.

Stanislav

[yemista]

wow, that was it. i still get a segmentation fault but that certainly changed things. Now I am able to load the isr address correctly into the idt, but there is still something wrong.

Code: Select all

<bochs:30> info idt 0x00
Interrupt Descriptor Table (base=0x00000088, limit=408):
IDT[0x00]=Code segment, laddr=f053f000, limit=0ff53 bytes, Execute/Read, Conforming, Accessed, 16-bit
<bochs:31> x /50 0x00100088
[bochs]:
0x00100088 <bogus+       0>:	0x00080022	0x00008e00	0x00080024	0x00008e00
0x00100098 <bogus+      16>:	0x00080026	0x00008e00	0x00080028	0x00008e00
0x001000a8 <bogus+      32>:	0x0008002a	0x00008e00	0x0008002c	0x00008e00
0x001000b8 <bogus+      48>:	0x0008002e	0x00008e00	0x00080030	0x00008e00
0x001000c8 <bogus+      64>:	0x00080032	0x00008e00	0x00080034	0x00008e00
0x001000d8 <bogus+      80>:	0x00080036	0x00008e00	0x00080038	0x00008e00
0x001000e8 <bogus+      96>:	0x0008003a	0x00008e00	0x0008003c	0x00008e00
0x001000f8 <bogus+     112>:	0x0008003e	0x00008e00	0x00080040	0x00008e00
0x00100108 <bogus+     128>:	0x00080042	0x00008e00	0x00080044	0x00008e00
0x00100118 <bogus+     144>:	0x00080046	0x00008e00	0x00080048	0x00008e00
0x00100128 <bogus+     160>:	0x0008004a	0x00008e00	0x0008004c	0x00008e00
0x00100138 <bogus+     176>:	0x0008004e	0x00008e00	0x00080050	0x00008e00
0x00100148 <bogus+     192>:	0x00080052	0x00008e00
<bochs:32> info idt 0x00
Interrupt Descriptor Table (base=0x00000088, limit=408):
IDT[0x00]=Code segment, laddr=f053f000, limit=0ff53 bytes, Execute/Read, Conforming, Accessed, 16-bit

That is how my idt appears in memory, and it seems to be set up right and they all have linear address, but info idt does not give the right linear address. laddr there should be 0x00100022 for the first entry. Also, what I dont get, it says 16-bit, but I read on wiki the E means 32 bit interrupt gate. I have never done any assembly programming on this level, but my only guess is maybe its not aligned right, or it has something to do with it being little endian. It is storing words in reverse order, so... i have no idea.... I shouldve just used grub....

[yemista]

I just noticed something that might be of importance. After loading the idt, heres what bochs tells me about it:

Code: Select all

<bochs:32> info idt 0x00
Interrupt Descriptor Table (base=0x00000088, limit=408):
IDT[0x00]=Code segment, laddr=f053f000, limit=0ff53 bytes, Execute/Read, Conforming, Accessed, 16-bit

Now, the base is given as 0x00000088, however, it is actually located at 0x00100088 because ds points to the base address 0x00100000. So, my question is, if someone with a working idt were to type info idt 0x00 at bochs, what would they get back? Should idt base be displayed as just an offset, or should if be a linear address that was calculated using the selector and offset. Maybe this is why Im getting a segmentation fault? An interrupt occurs and the cpu thinks the idt is at 0x00000088 and does not reference it through ds which would tell it it is really at 0x00100088, and it ends up trying to read garbage and failing.

[Firestryke31]

I don't think that the IDTR uses DS to offset the IDT for one simple reason: what if DS changes? Then the IDT would be different, and possibly invalid. Therefore, it uses the final linear address for the base, because the only way to change that is if you do it manually, which it assumes you know what you're doing.

You should try loading the final linear address (0x00100088) as the base. LIDT, however, does use DS, so don't change that.

Then again, most people use a flat memory model, so the final linear address and the offset into the segment end up being the same, so I may be wrong. But still, you should try it, and if it doesn't work, you're not much worse off than you were before...

[yemista]

ok, heres what the problem boils down to. DS just decides to stop working

This is ds before the lidt instruction

Code: Select all

<bochs:3> show "DS"
show param name: <DS>
DS = 
  selector = 0x10 (hex number)
  base = 0x100000 (hex number)
  limit = 0xfffff (hex number)
  limit_scaled = 0xfffff (hex number)
  ar_byte = 0x92 (hex number)
  granularity = false (boolean)
  d_b = true (boolean)
  avl = false (boolean)
<bochs:4> trace-mem on
Memory-Tracing enabled for CPU 0

The instruction appear to read from the right place

Code: Select all

<bochs:5> s
[CPU0 RD]: LIN 0x00100019 PHY 0x00100019 (len=4, pl=0): 0x00000088
[CPU0 RD]: LIN 0x00100017 PHY 0x00100017 (len=2, pl=0): 0x0198
Next at t=171041931
(0) [0x0010062c] 0008:0000062c (unk. ctxt): mov al, 0x11              ; b011

But the idtr is not pointing to the write place, and sure enough, where its pointing makes up the garbage points for my isrs.

Code: Select all

<bochs:6> info idt 0x00
Interrupt Descriptor Table (base=0x00000088, limit=408):
IDT[0x00]=Code segment, laddr=f053f000, limit=0ff53 bytes, Execute/Read, Conforming, Accessed, 16-bit
<bochs:7> x /4 0x00000088
[bochs]:
0x00000088 <bogus+       0>:	0xf000ff53	0xf000ff53	0xf000ff53	0xf000ff53

I cant see why this would happen.

[Combuster]

The IDT is in the linear address range, not the virtual address range.

Hence, segmentation does not apply for IDT accesses.

[yemista]

In that case, how do you load the idtr with a calculated linear offset that includes the base through ds? how can I make idtr 0x00100088 if I cant do it by lidt [ds:idt]?

[stlw]

In that case, how do you load the idtr with a calculated linear offset that includes the base through ds? how can I make idtr 0x00100088 if I cant do it by lidt [ds:idt]?

Open Intel manual and read about LIDT instruction:

Loads the values in the source operand into the interrupt descriptor table register (IDTR). The source operand specifies a 6-byte memory location that contains the base address (a linear address) and the limit (size of table in bytes) of the interrupt descriptor table (IDT).

pseudocode is trivial:
IDTR(Limit) ← SRC[0:15];
IDTR(Base) ← SRC[16:47];

and you decide what do you put in your memory location addressed by [ds:idt].
put there correct linear address as manual requires

Stanislav

[Firestryke31]

Basically, you give the LIDT instruction a pointer to the IDTR structure. The IDTR structure is the one that needs 0x00100088. So far it looks like you've been doing it almost right, but just put the wrong address into the IDTR structure.