From mboxrd@z Thu Jan 1 00:00:00 1970 From: Orjan Friberg To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: Hardware watchpoints; dealing with false triggers? Date: Fri, 30 Nov 2001 08:44:00 -0000 Message-id: <3C07B6FE.BBFA048D@axis.com> References: X-SW-Source: 2001-11/msg00614.html Eli Zaretskii wrote: > > On Thu, 29 Nov 2001, Orjan Friberg wrote: > > > But consider the following: say your watchpoint registers can only watch > > 4-byte aligned areas of 4 bytes, but you want to rwatch (or awatch) an > > unaligned variable of size 4 bytes. You'd have to use two watchpoint > > registers, both covering too much, like this: > > > > Variable to watch: | 0 1 2 3 | > > Watchpoints: | 0 1 2 3 | 0 1 2 3 | > > wp1 wp2 > > This shouldn't happen, and it indeed does not happen with x86. x86 uses > 2 debug registers in this case, like so: Eli, Many thanks for your detailed response. Maybe I should clarify that I'm not talking about the x86, but a hypothetical target whose watchpoint mechanism would function this way. I was only using the i386 hardware watchpoint implementation as a reference and a basis for discussion. > > Now, say a there's a read of wp1's byte 0. The hardware would trigger, > > but it would be a false trigger. Gdb would somehow have to find out the > > actual address that was read and if it was found to be outside of the > > variable's range it would not trigger the watchpoint. > > You can't do that, at least not with x86 debug registers: when a > watchpoint triggers, you don't know what byte of its covered memory was > written to. All you know is that memory covered by a specific register > was written. Ok, but say that the actual address is shipped with the register packet when the target stops so that gdb in fact knows what address was actually read/written. I'm thinking gdb could compare that address with the watchpoints, and just send the target on its way if the address is outside the watched ranges. I'm thinking of the implementation of this in a cross-environment, and while you could do it on the target side, say in the kernel, I'd rather not since I could potentially have several stubs. Handling it on the host side would allow me to handle it in one place only. > > are > > there any major obstacles for implementing such target-dependent false > > trigger handling in gdb? > > IIRC, no. If you cannot do something similar to what x86 does, I think > you are in for a bumpy ride, as GDB doesn't handle such problems very > well. Your best bet would be to solve this in the target-specific > low-level code. And this is the key issue: could the interface to the target-specific code be extended to handle the concept of "actual watchpoint address"? Or rather, could it be made to fit in nicely with the existing framework, or would it require a horrible kludge? (Maybe this question is on a too general level, and I just have to dig deeper into the code to see what would actually be needed.) > Do you really have such a strange target? Can you tell the details? No, I don't actually have such a target, so I'm sorry; I can't tell any details. -- Orjan Friberg Axis Communications AB From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9044 invoked by alias); 30 Nov 2001 16:44:10 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 8309 invoked from network); 30 Nov 2001 16:42:52 -0000 Received: from unknown (HELO miranda.axis.se) (193.13.178.2) by hostedprojects.ges.redhat.com with SMTP; 30 Nov 2001 16:42:52 -0000 Received: from ironmaiden.axis.se (ironmaiden.axis.se [10.13.8.120]) by miranda.axis.se (8.12.1/8.12.1/Debian -2) with ESMTP id fAUGgcXX029774; Fri, 30 Nov 2001 17:42:38 +0100 Received: from axis.com (localhost [127.0.0.1]) by ironmaiden.axis.se (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id RAA31192; Fri, 30 Nov 2001 17:42:38 +0100 X-Authentication-Warning: ironmaiden.axis.se: Host localhost [127.0.0.1] claimed to be axis.com Message-ID: <3C07B6FE.BBFA048D@axis.com> Date: Wed, 21 Nov 2001 17:14:00 -0000 From: Orjan Friberg Organization: Axis Communications AB X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sources.redhat.com Subject: Re: Hardware watchpoints; dealing with false triggers? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00399.txt.bz2 Message-ID: <20011121171400.TrkgiSacc67LSnRY0QKdsG4LzcIIHmV9zmkj8N44cCY@z> Eli Zaretskii wrote: > > On Thu, 29 Nov 2001, Orjan Friberg wrote: > > > But consider the following: say your watchpoint registers can only watch > > 4-byte aligned areas of 4 bytes, but you want to rwatch (or awatch) an > > unaligned variable of size 4 bytes. You'd have to use two watchpoint > > registers, both covering too much, like this: > > > > Variable to watch: | 0 1 2 3 | > > Watchpoints: | 0 1 2 3 | 0 1 2 3 | > > wp1 wp2 > > This shouldn't happen, and it indeed does not happen with x86. x86 uses > 2 debug registers in this case, like so: Eli, Many thanks for your detailed response. Maybe I should clarify that I'm not talking about the x86, but a hypothetical target whose watchpoint mechanism would function this way. I was only using the i386 hardware watchpoint implementation as a reference and a basis for discussion. > > Now, say a there's a read of wp1's byte 0. The hardware would trigger, > > but it would be a false trigger. Gdb would somehow have to find out the > > actual address that was read and if it was found to be outside of the > > variable's range it would not trigger the watchpoint. > > You can't do that, at least not with x86 debug registers: when a > watchpoint triggers, you don't know what byte of its covered memory was > written to. All you know is that memory covered by a specific register > was written. Ok, but say that the actual address is shipped with the register packet when the target stops so that gdb in fact knows what address was actually read/written. I'm thinking gdb could compare that address with the watchpoints, and just send the target on its way if the address is outside the watched ranges. I'm thinking of the implementation of this in a cross-environment, and while you could do it on the target side, say in the kernel, I'd rather not since I could potentially have several stubs. Handling it on the host side would allow me to handle it in one place only. > > are > > there any major obstacles for implementing such target-dependent false > > trigger handling in gdb? > > IIRC, no. If you cannot do something similar to what x86 does, I think > you are in for a bumpy ride, as GDB doesn't handle such problems very > well. Your best bet would be to solve this in the target-specific > low-level code. And this is the key issue: could the interface to the target-specific code be extended to handle the concept of "actual watchpoint address"? Or rather, could it be made to fit in nicely with the existing framework, or would it require a horrible kludge? (Maybe this question is on a too general level, and I just have to dig deeper into the code to see what would actually be needed.) > Do you really have such a strange target? Can you tell the details? No, I don't actually have such a target, so I'm sorry; I can't tell any details. -- Orjan Friberg Axis Communications AB