Hi,
I Dont exactly know how it does it. But then these
systems must have some method (exception) of
telling the kernel that the address on the bus is invalid.
Didnt think about this when I was working on non-MMU
based linux systems. All I remember is that we could
access the hardware from the userspace. That is userspace
drivers. Makes programming lot more easier :-).
For the exact details I think you should go thru the traps.c of
a non-mmu architecture.
Eg. try arch/m68knommu/kernel/traps.c
--
Kishore A K
On Thu, 18 Nov 2004 16:26:16 +0530, Mandeep Sandhu
<mandeep_sandhu@xxxxxxxxxxx> wrote:
> On Thu, 2004-11-18 at 16:18, Kishore A K wrote:
>
>
> > Hi,
> >
> > >-the kernel does NOT handle null pointer derefernce,
> > >the compiler does!
> >
> > I dont know how you concluded that null pointer dereferences
> > that happen in runtime are handled by the compiler. NULL
> > pointer dereferences can be caught by the hadware or by
> > the kernel.
> >
> > Addresses used by the processor are virtual addresses which
> > map into actual physical addresses by paging mechanisms.
> > When an NULL pointer is dereferenced, the paging mechanism
> > fails to map the pointer to a valid physical address and the
> > processor signals a page fault to the kernel. Since the address
> > is not valid, the kernel fails to page in the right address. It
> > generates an oops if this happens from inside the kernel or
> > a segmentation fault when from the userspace.
> >
> yeah, your absolutely right there. The kernel figures out when
> to oops in it page fault handler. thanks for clearing that.
>
> but what happens on MMU-less systems where evry address is directly
> mapped to phy. addr.?
>
>
>
> > For more details about the fault handler refer arch/i386/kernel/traps.c.
> >
> > Regards,
> > Kishore A K
> >
> > "Dream as if you'll live forever; Live as if you'll die today."
> >
> >
> > On Thu, 18 Nov 2004 14:52:36 +0530, Mandeep Sandhu
> > <mandeep_sandhu@xxxxxxxxxxx> wrote:
> > > did some googling and search the LKML archives.
> > > the jist of the story (DISCLAIMER: according to me :))
> > >
> > > -the kernel does NOT handle null pointer derefernce,
> > > the compiler does!
> > > -for the C porgramming language NULL is *generally*
> > > (but not strictly!) defined as 0. Therefore it is
> > > the compilers job to see if 0 is being used in a
> > > pointer context, and convert it into a bit pattern
> > > that translates into an invalid addrress for a
> > > particular h/w (the CPU catches invalid mem. addr
> > > exceptions).
> > > -0 on some arch.s *is* a valid address.
> > > -If on your system uses the value of NULL other than 0,
> > > you need to tell the compiler as well.
> > >
> > > (i have a feeling i'm going to get flamed for this!)
> > >
> > >
> > >
> > > On Thu, 2004-11-18 at 14:35, Vishal Soni wrote:
> > > > > I remember a big discussion happening on LKML on this
> > > > > topic (i.e., NULL vs 0) a couple of months back. It must
> > > > > be still available in their mail archives. Try googling for
> > > > > "Use NULL instead of integer 0" & you must find it. Must
> > > > > say it was a pretty heated discussion. Dont know what
> > > > > the outcome was. I stopped following it after sometime.
> > > > Tried some thing and pasting a copy here...which tells clearly abt NULL
> > > > pointer and using zero(integer)
> > > > C code -- used
> > > > file name : null.c
> > > > int main()
> > > > {
> > > > int *p= NULL;
> > > > return 0;
> > > > }
> > > >
> > > > file name : zero.c
> > > > int main()
> > > > {
> > > > int p = 0;
> > > > return 0;
> > > > }
> > > >
> > > > Assembly snippet on 64 bit machine for null.c
> > > > main:
> > > > .LFB3:
> > > > pushq %rbp
> > > > .LCFI0:
> > > > movq %rsp, %rbp
> > > > .LCFI1:
> > > > movq $0, -8(%rbp) <------------
> > > > movl $0, %eax
> > > > leave
> > > > ret
> > > >
> > > > Assembly snippet on 64 bit machine for zero.c
> > > > main:
> > > > .LFB3:
> > > > pushq %rbp
> > > > .LCFI0:
> > > > movq %rsp, %rbp
> > > > .LCFI1:
> > > > movl $0, -4(%rbp) <-------------
> > > > movl $0, %eax
> > > > leave
> > > > ret
> > > > Check out the 7th line..... of both the snippets
> > > > If we see here 8 bytes are deducted from base pointer(in 64 bit machine --
> > > > when variable p was NULL pointer)
> > > > and 4 bytes are deducted from rbp when p was integer....(obvious... Right
> > > > !!!!)
> > > > and thus the code differs.......
> > > >
> > > > Whereas in 32 bit machine, assembly snippets for null.c and zero.c are
> > > > similar.
> > > > main:
> > > > pushl %ebp
> > > > movl %esp, %ebp
> > > > subl $8, %esp
> > > > andl $-16, %esp
> > > > movl $0, %eax
> > > > addl $15, %eax
> > > > addl $15, %eax
> > > > shrl $4, %eax
> > > > sall $4, %eax
> > > > subl %eax, %esp
> > > > movl $0, -4(%ebp)
> > > > movl $0, %eax
> > > > leave
> > > > ret
> > > >
> > > > Interesting conclusions and concept to imbibe :)
> > > > Regards,
> > > > Vishal.
> > > >
> > >
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
>
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
