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.
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/
