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/
