From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Cownie To: Mark Kettenis Cc: gdb@sources.redhat.com, eliz@is.elta.co.il Subject: Re: gdb doesn't work very well with dynamic linked binaries Date: Thu, 07 Sep 2000 03:27:00 -0000 Message-id: <200009071027.GAA00898@albacore> X-SW-Source: 2000-09/msg00075.html > I think I understand the problems now. It basically means that one > cannot reliably watch area's that are somehow used in system calls. There are two slightly separate issues here 1) If the kernel triggers a watchpoint do you get to see it 2) If the kernel triggers a watchpoint does that break subsequent user level watchpoints. The ideal behaviour, of course, would be that you saw the watchpoint whether or not it was triggered by the kernel, and that didn't break anything. (I believe this is what 2.0 kernels achieved). The current (2.2.17) Linux behaviour is that 1) The kernel triggered watchpoint is not reported to the debugger *AND* 2) After the watchpoint is triggered by the kernel _all_ watchpoints in the thread are disabled until it gets rescheduled. (So some arbitrary number of user level watchpoint hits can be missed). My patch would remove the second property, but would still leave us ignorant about watchpoint hits from the kernel. So, with my kernel patch all watchpoint hits from user space are reported, but watchpoint hits from kernel space are ignored. (Therefore reading over a watched area doesn't get reported). The ideal patch would also report kernel watchpoint hits back to the process. Unfortunately I don't see any "free" way of doing that. (By which I mean a way which doesn't add code to the system call return path whether or not debugging is enabled). The current bug was introduced in the move from 2.0 to 2.2 because the system call return path was optimised to remove the restoration of the debug registers (which is fine as long as the kernel doesn't change them, unfortunately it does). > I suspect that Linux isn't the only kernel with this bug. AFAICS > FreeBSD also simply disables any (user-space) watchpoints triggered > from within the kernel. I don't know what the various x86 System V's > (Solaris, SCO Open Server 5) do, but I wouldn't be surprised if it is > broken there too. It all depends on whether these OSes restore the debug registers in the system call return path. If so changing them in the kernel is OK. -- -- Jim James Cownie jcownie@etnus.com Etnus, Inc. Phone +44 117 9071438