At Thu, 18 Nov 2004 16:26:16 +0530,
Mandeep Sandhu 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.?
>
Nothing happens, you are just writing to pointer 0 (assuming that it is a legal
address on that architecture, otherwise the hardware could still generate a
fault even without the MMU, but I don't know if there is such hardware, so that
is theoretical).
Its just the same as writing to any other piece of memory thats not yours, if
its a legal address and there is no mmu it will go through without problem (some
of the head aches of using mmu-less systems).
> > 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/
>
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
