Crashing using non-default constructor

[Qeroq]

Hello,
in my kernel there are three classes, which inherit from each other: AMD64RecursiveAddressSpace inherits from AMD64AddressSpace which in turn inherits from AddressSpace. Only AMD64RecursiveAddressSpace has no pure virtual methods and requires a non-default constructor for passing a physical memory manager. But every time I passed a value to it, it died, without any message, even when I changed to a plain integer that is passed. When I change back to a no-argument constructor the kernel does not crash, but the constructor does not seem to be executed (a while(1); does not halt the system). Maybe it should be mentioned that although I linked the kernel to 1MB and identity mapped the first two megs in bootstrap (AMD64), pointers to my objects (no malloc yet!) are always below the 1MB mark, like 0x7FDC8, for some reason. I'm trying to set up interrupts now (I planned to write the code after the memory manager, but set it up first, of cause), seeing if I can get more information about the problem.

Thank you,
Farok

[Solar]

Time to apply Solar's Machete.

[Qeroq]

With died I meant the very early stage kind of dying, rebooting, and it dies in exactly this creation of the AMD64RecursiveAddressSpace object:

Code: Select all

AMD64RecursiveAddressSpace kernelAddrSpace(&kernelHeap);

The object dump gives this for the important section:

Code: Select all

0000000000000000 <_ZN6Oxygen4Core12MemoryMapperINS0_5AMD6417AMD64AddressSpaceEEC2Ev>:
   0:	55                   	push   %rbp
   1:	48 89 e5             	mov    %rsp,%rbp
   4:	48 83 ec 08          	sub    $0x8,%rsp
   8:	48 89 7d f8          	mov    %rdi,-0x8(%rbp)
   c:	48 8b 45 f8          	mov    -0x8(%rbp),%rax
  10:	48 c7 00 00 00 00 00 	movq   $0x0,(%rax)
  17:	c9                   	leaveq 
  18:	c3                   	retq

What I noticed is, that there is no call in there, as it is in the respective code of the other objects, although a constructor is there for this one, too (no inline one either).

Sorry for giving so few info, I usually give more, but this time I didn't really know where to look at (yeah, I've done this kind of debugging, but I wrote that) and assumed it's more of a common problem that everyone has encountered somewhen.

[Solar]

*sigh*

Cut down the kernel code required to reproduce the problem to a minimum.

Then seperate the problems:

Create a lookalike code sample that does the same inheritance / parameter passing in user space, and test that.

On a different angle, find out what is linked where in your kernel, and why.

Don't guess. Find out.