Date: Tue, 22 Aug 2000 20:07:18 +0300 From: Peter Pentchev <roam@orbitel.bg> To: Zhihui Zhang <zzhang@cs.binghamton.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: kernel debugging on 4.1-release Message-ID: <20000822200718.F58183@ringwraith.office1.bg> In-Reply-To: <Pine.SOL.4.21.0008221234370.9065-100000@sol.cs.binghamton.edu>; from zzhang@cs.binghamton.edu on Tue, Aug 22, 2000 at 12:44:14PM -0400 References: <Pine.SOL.4.21.0008221234370.9065-100000@sol.cs.binghamton.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 22, 2000 at 12:44:14PM -0400, Zhihui Zhang wrote:
>
> I try to trace some system call using remote debugging and find something
> that I can not explain myself (the related source is ffs_write()):
>
> case 1:
> -------
>
> 443 if (object)
> (gdb) break 430
> Breakpoint 6 at 0xc0289cea: file ../../ufs/ufs/ufs_readwrite.c, line 430.
> (gdb) c
> Continuing.
>
> Breakpoint 6, ffs_write (ap=0xc64f5e70) at
> ../../ufs/ufs/ufs_readwrite.c:438
> 438 p = uio->uio_procp;
>
> In the above case, even if I set breakpoint 6 at line 430, it insists on
> line 438.
This is caused by compiler optimization - gcc notices lines 430 and 438
are the same (actually not the lines themselves, but the relevant blocks
of code, which may have nothing to do with source organization in lines),
and only generates the code once. For debugging purposes, it stores debug
information that it has done so - and gdb knows that a breakpoint on line
430 should actually be placed at the code fragment corresponding to line 438.
>
> case 2:
> -------
>
> (gdb) print p->p_limit
> $1 = (struct plimit *) 0xffffffff
>
> In the above case, the statement has just used p->p_limit to do some
> comparison and yet gdb says its value is -1. The statement using it is:
>
> if (vp->v_type == VREG && p &&
> uio->uio_offset + uio->uio_resid >
> p->p_rlimit[RLIMIT_FSIZE].rlim_cur) {
I'm not quite sure about this one, but it might very well be also related
to gcc optimizing something out; I've cursed it more than once, trying to
debug things compiled with -O -g, and finding some of my local vars totally
gone, common subexpressions eliminated or only calculated once, whole dead
code branches gone, and the like :)
For debugging without tearing more than half of your hair out, compile
the kernel with no -O options and with some kind of -g options; I personally
use -ggdb -g3 for more gdb-targeted output (though I would be the first
to admit I know nothing about just what does gcc do that is gdb-targeted :)
G'luck,
Peter
--
The rest of this sentence is written in Thailand, on
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000822200718.F58183>