From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27511 invoked by alias); 6 Sep 2010 20:48:30 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 27501 invoked by uid 22791); 6 Sep 2010 20:48:29 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_XC,T_RP_MATCHES_RCVD,URIBL_RHS_DOB X-Spam-Check-By: sourceware.org Date: Mon, 06 Sep 2010 20:48:00 -0000 From: Oleg Nesterov To: Jan Kratochvil Cc: archer@sourceware.org, utrace-devel@redhat.com Subject: Re: gdbstub initial code, v8 Message-ID: <20100906204446.GA29925@redhat.com> References: <20100903224047.GA8917@redhat.com> <20100905194101.GA31584@host1.dyn.jankratochvil.net> <20100906181808.GA22839@redhat.com> <20100906183142.GA3256@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100906183142.GA3256@host1.dyn.jankratochvil.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00153.txt.bz2 On 09/06, Jan Kratochvil wrote: > > On Mon, 06 Sep 2010 20:18:08 +0200, Oleg Nesterov wrote: > > On 09/05, Jan Kratochvil wrote: > > > > > (also to put in breakpoints): > > > > And this is not clear to me, I need your help ;) > > Sorry, I just meant that by implementing the memory writes breakpoints > automatically start to work. > > > > What should ugdb know about breakpoints? I played with the real > > gdbserver, and afaics gdb just changes the tracee's memory and > > inserts 0xcc (int 3). But gdb.info mentions "Z TYPE,ADDR,KIND" > > packets. > > I believe it is described by: > /* If GDB wanted this thread to single step, we always want to > report the SIGTRAP, and let GDB handle it. Watchpoints should > always be reported. So should signals we can't explain. A > SIGTRAP we can't explain could be a GDB breakpoint --- we may or > not support Z0 breakpoints. If we do, we're be able to handle > GDB breakpoints on top of internal breakpoints, by handling the > internal breakpoint and still reporting the event to GDB. If we > don't, we're out of luck, GDB won't see the breakpoint hit. */ > > > > So, what should ugdb do? Just implement memory write (M or X) > > and then report SIGTRAP like gdbserver does? > > Therefore until you track some ugdb-specific software(*) breakpoints ugdb does > not need to support Z0 IMO. I guess ugdb will never have to support these: > thread-related(?) and tracepoint ones. Good! I thought ugdb should somehow handle this all "transparently" for gdb. I thought (I don't know why) that writing "int 3" from gdb side should be avoided in favour of some "better" method unknown to me. Thanks Jan. Oleg.