From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32724 invoked by alias); 29 Sep 2009 05:19:46 -0000 Received: (qmail 32713 invoked by uid 22791); 29 Sep 2009 05:19:44 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Sep 2009 05:19:38 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 75D262BAB55; Tue, 29 Sep 2009 01:19:36 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WFq2CKR3Eqrh; Tue, 29 Sep 2009 01:19:36 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 3EA402BAB4B; Tue, 29 Sep 2009 01:19:36 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id A6E96F593D; Mon, 28 Sep 2009 22:19:29 -0700 (PDT) Date: Tue, 29 Sep 2009 05:19:00 -0000 From: Joel Brobecker To: Caz Yokoyama Cc: 'Pedro Alves' , gdb-patches@sourceware.org Subject: Re: symbolic debug of loadable modules with kgdb light Message-ID: <20090929051929.GL9003@adacore.com> References: <20090923004802.GA20859@adacore.com> <9ECED0F0DCF04CC185B027503876430D@xpjpn> <20090925160627.GB5077@adacore.com> <66E35EA6599040F894D040E4F50389D0@xpjpn> <535d47e30909260627n662135a1hf6d1a0bb33368b3a@mail.gmail.com> <20090929015830.GJ9003@adacore.com> <1724490614004CEB9EE1A091A151E05B@xpjpn> <20090929042226.GK9003@adacore.com> <2C14068798BA41219F3603CDD24C8BC0@xpjpn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2C14068798BA41219F3603CDD24C8BC0@xpjpn> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2009-09/txt/msg00907.txt.bz2 > I know Magic SysRq is the one for Linux kernel. I planned to propose BREAK > for Xen hypervisor if my patch were approved. I don't know what > interrupt_sequence is on other OSes. However, I believe that introducing the > possible variations into gdb is not your intention. You don't want to change > the code when OS changes its interrupt_sequence or supporting new OS. In my opinion, if you have a debugger that works with BREAK, this will help supporting your suggestion to use BREAK. If you want extensibility while at the same time being able to check the value entered by the user, then perhaps the solution is with the use of an XML file, similar to what has been done for the "catch syscall" command. I am not very familiar with this part of the debugger, but other maintainers are. However, I think you're worriying about something that may or may not become an issue. I'm not saying it is a bad thing, but you have something that's very close to acceptable and will work for your current situation (current Linux kernel). Was it Lean Programming that said fix a weakness only when it becomes an issue? With the current proposed user interface, I believe we should be able to expand the implementation to accomodate other various sequences. > >Please let us also know if you'd prefer someone else to review your > patches. > I am new to gdb mailing list. I know nobody who is a maintainer of gdb. What I meant to imply is that, if you think there is a problem with my reviews, I can ask someone else from the group of maintainers to take over this thread. -- Joel