From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25324 invoked by alias); 26 Mar 2009 23:10:17 -0000 Received: (qmail 25307 invoked by uid 22791); 26 Mar 2009 23:10:15 -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; Thu, 26 Mar 2009 23:10:09 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 162EB2BAC47; Thu, 26 Mar 2009 19:10:08 -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 VXwJezMtuhrm; Thu, 26 Mar 2009 19:10:08 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A74E62BAC46; Thu, 26 Mar 2009 19:10:07 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id A4D1E5BD21; Thu, 26 Mar 2009 16:09:59 -0700 (PDT) Date: Thu, 26 Mar 2009 23:18:00 -0000 From: Joel Brobecker To: Pierre Muller Cc: gdb-patches@sourceware.org, gdb@sourceware.org, 'Eli Zaretskii' Subject: Re: GDB ARIndex cleanup Message-ID: <20090326230959.GN9472@adacore.com> References: <000001c9ae14$24fb7cd0$6ef27670$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c9ae14$24fb7cd0$6ef27670$@u-strasbg.fr> 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-03/txt/msg00603.txt.bz2 > 1) "inline" > for inline, someone once said that the rule that we should not use > "inline" keyword is old, and maybe not correct anymore. > > If everyone agrees that this rule should stay, I will be happy to > commit an obvious fix removing all of them as this seems quite > mechanical, but I wanted to get some feedback first. I don't know much about the effectiveness of using "inline". I personally tend to avoid it, because I trust the compiler to determine whether an inline will help or not. So I'm OK either way. > This is more difficult for me to fix, as > the difference between "Linux kernel" and "GNU/Linux system" > is still kind of fuzzy... As a first guess, I think a lot of the references will be to the Linux kernel. GDB interfaces mostly with the kernel. GNU/Linux would refer to the larger systems that runs on the Linux kernel. However, I'm wondering if this rule is really all that helpful for the GDB project or not. I suspect this comes from a request from RMS to make sure that this distinction be made in GNU code. But it might seem a bit awkward when you read it. > /* Linux target descriptions. */ I'm actually not 100% sure about this one. I think that target descriptions can be used to describe other things than register availability and numbering. So, generally speaking, the above might be ambiguous. But in practice, the target_desc below are describing registers, so Linux Kernel. Again, not 100% sure. > /* The list of issues to contend with here is taken from > resume_execution in arch/x86/kernel/kprobes.c, Linux 2.6.28. > Yay for Free Software! */ Kernel. > When waiting for an event in all threads, waitpid is not quite good. Prior > to > version 2.4, Linux can either wait for event in main thread, or in secondary Kernel. > /* The length of the longest i386 instruction (according to > include/asm-i386/kprobes.h in Linux 2.6. */ Kernel (he's talking about the kernel sources) > /* Wrappers to handle Linux-only registers. */ Kernel. > /* Initialize the Linux target descriptions. */ Kernel. Again, sounds pretty awkward to use "Linux Kernel target descriptions". -- Joel