From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24871 invoked by alias); 9 Jan 2009 19:33:52 -0000 Received: (qmail 24860 invoked by uid 22791); 9 Jan 2009 19:33:51 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.178) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Jan 2009 19:33:40 +0000 Received: by wa-out-1112.google.com with SMTP id v33so5540370wah.24 for ; Fri, 09 Jan 2009 11:33:38 -0800 (PST) Received: by 10.114.74.18 with SMTP id w18mr17092298waa.40.1231529617423; Fri, 09 Jan 2009 11:33:37 -0800 (PST) Received: from xpjpn (pool-71-111-133-125.ptldor.dsl-w.verizon.net [71.111.133.125]) by mx.google.com with ESMTPS id m27sm38801183pof.27.2009.01.09.11.33.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Jan 2009 11:33:36 -0800 (PST) To: "'Joel Brobecker'" Cc: References: <20090109041826.GD20227@adacore.com> <20090109181720.GD31296@adacore.com> Subject: RE: symbolic debug of loadable modules with kgdb light Date: Fri, 09 Jan 2009 19:33:00 -0000 Message-ID: <775C643571C64E14B8E46DD6AD32EAED@xpjpn> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: <20090109181720.GD31296@adacore.com> From: Caz Yokoyama 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: 2009-01/txt/msg00048.txt.bz2 Joel, Thank you for your comments. I'll minimize the modification as little as possible and find if there is code comes from http://kgdb.cvs.sourceforge.net/viewvc/kgdb/gdb/. -caz -----Original Message----- From: Joel Brobecker [mailto:brobecker@adacore.com] Sent: Friday, January 09, 2009 10:17 AM To: Caz Yokoyama Cc: gdb@sourceware.org Subject: Re: symbolic debug of loadable modules with kgdb light Caz, I have a few remarks: > I have attached the patch against gdb-6.8. The patches first need to be brought up to date with our CVS head. Our gdb-6.8 branch is more or less dead at this point, and the current CVS head is sometimes significantly different from gdb-6.8. Also, the patches should be broken down into small patches. I don't know how well the other maintainers know the Linux kernel (I suspect some of them know it very well), but most of us don't have much time available to do code review. So breaking down the patches and explaining what they are about is very very very very very very helpful. If you don't do that, unless someone from the GDB Maintainers group is expecially motivated in getting the feature you are submitting, you are dramatically reducing your chances of us reviewing your patch. > - This patch is based on http://kgdb.cvs.sourceforge.net/viewvc/kgdb/gdb/. I > removed garbage as mush as possible. I tried to have a look at who the authors are. The changes need to be assigned to the FSF. I'm not a big specialist in legal matters, but I believe that only the author of the changes can do that; someone else who knows better about might want to confirm or correct. There is a provision for changes that are obvious, or small (usually less than 10 lines). But this patch does not qualify. Some parts of it might. > But it still has the code which I don't know what it is. As far as I am concerned, this is a problem. I personally am not going to approve changes whose purpose I don't understand. My approach in this case has always been to leave the change aside, and wait until I hit a problem. If that change ends up fixing the problem, at least I will know why (and I will make sure to add a comment besides the code). > - I haven't run testsuite because I could not find how to do that while I > run make in testsuite directory. The magic command for testing your changes natively is "make check". What you need to do is run the testsuite before and after your changes, and make sure that it does not introduce any regression. Somes parts of the patch will be hard to exercise except manually, since they refer to debugging kernel modules, which I don't think is something that our testsuite knows how to do... I hope all the above doesn't discourage you... -- Joel