From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28013 invoked by alias); 19 Oct 2012 00:31:56 -0000 Received: (qmail 28005 invoked by uid 22791); 19 Oct 2012 00:31:55 -0000 X-SWARE-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,BAYES_00,KHOP_DNSBL_ADJ,KHOP_THREADED,RCVD_IN_BRBL_LASTEXT,RCVD_IN_HOSTKARMA_YE,RCVD_IN_MSPIKE_BL,RCVD_IN_MSPIKE_L3,RCVD_IN_NJABL_RELAY,RCVD_IN_PSBL,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from new.toad.com (HELO new.toad.com) (209.237.225.253) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Oct 2012 00:31:50 +0000 Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q9J0Sd2N005583; Thu, 18 Oct 2012 17:28:39 -0700 Message-Id: <201210190028.q9J0Sd2N005583@new.toad.com> To: Pedro Alves cc: Michal Lesniewski , gdb@sourceware.org, "'Yao Qi'" Subject: Re: Implementation of different software breakpoint kinds in gdb server In-reply-to: <507FEF69.4030008@redhat.com> References: <000001cdad12$1e2b1950$5a814bf0$%lesniewski@samsung.com> <507FD526.5080604@redhat.com> <000101cdad25$e3eda550$abc8eff0$%lesniewski@samsung.com> <507FEF69.4030008@redhat.com> Comments: In-reply-to Pedro Alves message dated "Thu, 18 Oct 2012 13:00:41 +0100." Date: Fri, 19 Oct 2012 00:31:00 -0000 From: John Gilmore X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-10/txt/msg00086.txt.bz2 > It's not the next_pc bits per se, but the run control stuff that always > gets tricky. Well, every time I think touching run control stuff in either > gdb or gdbserver shouldn't be hard, I spend long whiles head banging. > Maybe it's just me. :-) It's not just you. For the first few years that I maintained GDB in the 1990s, whenever I changed something in that big wait_for_inferior jungle, I would introduce two bugs for every bug I fixed. I got pretty cautious about messing around in there. Eventually I started factoring the huge function into smaller functions, which reduced the conceptual complexity somewhat. Also, I gradually got better at learning what would break it, and we also built up a test suite that could test for obvious breakages. > It'd be nice to avoid the duplication, though that might not be easy. If you DO end up moving any of this infrastructure into the target environment, I strongly recommend using common code. It is hard enough to debug it once -- let alone debugging it separately on each target as they evolve separate versions of this very complicated code. John