From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21848 invoked by alias); 24 Jan 2012 05:54:28 -0000 Received: (qmail 21839 invoked by uid 22791); 24 Jan 2012 05:54:27 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Jan 2012 05:54:14 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RpZKf-00069K-Vn; Tue, 24 Jan 2012 00:54:13 -0500 Date: Tue, 24 Jan 2012 08:04:00 -0000 Message-Id: From: Eli Zaretskii To: Yao Qi CC: gdb-patches@sourceware.org In-reply-to: <4F1DFC61.2080802@codesourcery.com> (message from Yao Qi on Tue, 24 Jan 2012 08:33:37 +0800) Subject: Re: [patch 5/8] Doc for agent Reply-to: Eli Zaretskii References: <4F1D55D7.7030506@codesourcery.com> <4F1D678B.2040705@codesourcery.com> <837h0i2uf9.fsf@gnu.org> <4F1DFC61.2080802@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00808.txt.bz2 > Date: Tue, 24 Jan 2012 08:33:37 +0800 > From: Yao Qi > CC: > > >> +the bug. In order to overcome the interference, we should reduce the number of > >> +operations debugger performed. > > ^^^^^^^^^^^^^^^^^^ > > "preformed by the debugger". > > > > Again, I think the issue is not the number of operations, but > > interference with the program's timing. > > > > Yes, the issue is the interference with the program's timing. We want > to fix this issue, to some extent, by reducing the number of operations > here. Of course, there are other approaches to reduce interference. > > How about change this sentence like this, > > "In order to reduce the interference with the program, we can reduce the > number of operations performed by the debugger." OK. > > >> @dfn{Agent}, a shared library, is running within > >> +the same process with inferior, and is able to perform some debugging operations > >> +itself. As a result, debugger is only involved when necessary, and performance > >> +of debugging can be improved accordingly. > > > > But this is a half-measure, isn't it? The agent will still stop or > > slow down the program's threads, and so still influences its timeline, > > right? > > > > Right. Interference can be reduced, but can't be removed completely. It might be a good idea to say that. Otherwise, the wording sounds as if using the agent solves this problem completely. > >> -In some applications, it is not feasible for the debugger to interrupt > >> -the program's execution long enough for the developer to learn anything > >> -helpful about its behavior. If the program's correctness depends on its > >> -real-time behavior, delays introduced by a debugger might cause the > >> -program to fail, even when the code itself is correct. It is useful to > >> -be able to observe the program's behavior without interrupting it. > > > > See, this text describes the issue more correctly, IMO, but it looks > > like you deleted it and not moved it to the new chapter. > > I remove this paragraph because it fits to the concept of tracepoint > ("observer the program's behavior without interrupting it"), and the > agent work can do more than that. What can it do in addition? I don't think your new text said anything about that. > I don't mind putting it back at the > the beginning of chapter "Debugging Agent" as another problem statement. I think it should be the only statement of the problem. If the agent has additional benefits, their description should be added to the above text.