From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19135 invoked by alias); 29 Sep 2009 16:39:27 -0000 Received: (qmail 19125 invoked by uid 22791); 29 Sep 2009 16:39:25 -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 16:39:19 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id EF5C62BAB73; Tue, 29 Sep 2009 12:39:17 -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 5wndzNT1ippf; Tue, 29 Sep 2009 12:39:17 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id BA5AB2BAB27; Tue, 29 Sep 2009 12:39:17 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 98B4FF593D; Tue, 29 Sep 2009 09:39:10 -0700 (PDT) Date: Tue, 29 Sep 2009 16:39: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: <20090929163910.GO9003@adacore.com> References: <9ECED0F0DCF04CC185B027503876430D@xpjpn> <20090925160627.GB5077@adacore.com> <66E35EA6599040F894D040E4F50389D0@xpjpn> <535d47e30909260627n662135a1hf6d1a0bb33368b3a@mail.gmail.com> <20090929015830.GJ9003@adacore.com> <1724490614004CEB9EE1A091A151E05B@xpjpn> <20090929042226.GK9003@adacore.com> <2C14068798BA41219F3603CDD24C8BC0@xpjpn> <20090929051929.GL9003@adacore.com> <7063C3E99BE344B2B98EDC0318ED852A@xpjpn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7063C3E99BE344B2B98EDC0318ED852A@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/msg00924.txt.bz2 > Do you think we have to check correctness of user input for > interrupt_sequence? Yes, if only for the vast majority of users who will be using either the default or using BREAK. > Setting-up debugging environment of Linux device driver by gdb is not > a trivial task I don't doubt that, and I do not doubt that users prefer flexibility. The current solution, which offers the user 3 choices for the interrupt sequence, has no kernel dependency. It's very clear what each choices does, and I do not understand how allowing free text instead of a defined set of choices helps make things easier, especially when only specific choices will actually be accepted in the end. You are arguing that we may need more choices in the future. I answered that we can worry about that later, *when/if* the situation actually arises. Adding more choices is a matter of seconds with a 10-line patch. But, again, I also repeat that, if you think this is unnacceptable, then perhaps we can accomodate extensibility while not needing code recompilation by using a technical solution based on XML. You can have a look at how "catch syscall" is implemented for an illustration. But this can be done as a second phase, after the patch on which you've been working on is approved and checked in. In other words: 1. Implement a patch that adds: set/show remote interrupt-sequence set/show remote interrupt-at-startup [on|off] Make the old set/show remotedebug deprecated (please take a look at my earlier reply on what I mean by that) 2. Look into adding extensibility through the use of an XML file If you prefer to do all the work in one patch, you are welcome to do so, but you are letting the best be the enemy of good, IMO, and only delaying the time when vanilla FSF GDB can debug Linux Kernel modules. -- Joel