Re: More on oskit-mach debugging

[Igor Khavkine]

Jeroen Dekkers wrote:
> 
> On Fri, Jul 13, 2001 at 09:21:57AM -0400, Igor Khavkine wrote:
> > Now if I was still linking with the version of oskit in the Hurd archives
> > all my problems would be solved and I would be able to boot properly.
> > However, I have compiled my own version of OSKit to get debigging
> > symbols. Now I get a SIGSEVG during initialization in the OSKit
> > function `oskit_linux_dev_init () at [oskit]/linux/dev/init.c:81',
> > on line:
> >
> > 129             x = *((unsigned *)(kaddr + 0x104));
> >
> > Here `kaddr' has value 0x0 and the calculated address 0x104 is not
> > accessibl, hence the SIGSEGV. Lets see how `kaddr' gets its
> > value:
> >
> > 127     if (osenv_mem_map_phys(0, PAGE_SIZE, &kaddr, 0))
> > 128             panic("%s:%d: unable to map phys memory", __FILE__, 
> > __LINE__);
> >
> > Once all the functions are followed through and all macros expanded,
> > the result comes down to the following:
> >
> > kaddr = phystokv(0) = 0 + phys_mem_va
> >
> > And at the moment the value of phys_mem_va is also 0x0, hence `kaddr = 0x0'.
> >
> > My question is, when during oskit-mach's initialization does the paging
> > turn on, and why isn't phys_mem_va set to the correct value?
> >
> 
> There was my previous trap.c patch about (see that mail for the patch). First
> I thought the same thing as you, but in gnumach and the example kernels
> phys_mem_va is also set to 0.
> 
> When I looked further, I ended in the page fault handling code. If
> trunc_page(subcode) == 0, the kernel panics. After macro expansion that means
> if subcode (the value of the address) is smaller than the page size,
> trunc_page(subcode) is 0 and thus gives a panic.

I've found your mail and see that you've reported this already.

> Because 0x104 is smaller than PAGE_SIZE (0xfff iirc), the kernel page faults.
> I just removed the check and everythings works ok. Well, oskit-mach still
> doesn't work, but I get the same as with the debian packges. The fact that
> this problem only occurs when you built the oskit yourself is that with the
> debian package oskit_linux_dev_init is never called afaik, I don't know why.

I think the reason, for the check trunc_page(subcode) == 0 is to guard against
NULL pointer references. Usually in user processes the 0th page is protected
in such a way as to produce a SIGSEGV instead of letting the user overwrite
memory at that location. But inside the kernel, this might be a little trickier.
Myabe if the the kernel is mapped starting at the 1st page
(phys_mem_va = PAGE_SIZE) then it would work without your change.

I'd still like to know when/where exactly is the paging table and phys_mem_va
are set up in the code.
 
> I'm almost finished hacking remote debugging support with ethernet. If it
> works I will post it here, but it's only a dirty hack. Anyway you can also
> contact me on #hurd at openprojects, my nickname is F399.

As you might have guessed, my nick is \Igor\, see you there.

Igor