From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10865 invoked by alias); 4 Oct 2004 16:35:35 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10852 invoked from network); 4 Oct 2004 16:35:33 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 4 Oct 2004 16:35:33 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CEVoD-0003RB-7v; Mon, 04 Oct 2004 12:35:33 -0400 Date: Mon, 04 Oct 2004 16:35:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Build inf-ptrace.o when ptrace available Message-ID: <20041004163533.GA12898@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , gdb-patches@sources.redhat.com References: <415DC09D.2070407@gnu.org> <200410012154.i91Ls6lE001359@elgar.sibelius.xs4all.nl> <41615D1E.8070007@gnu.org> <20041004143416.GA6653@nevyn.them.org> <416179DE.70401@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416179DE.70401@gnu.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-10/txt/msg00056.txt.bz2 On Mon, Oct 04, 2004 at 12:27:10PM -0400, Andrew Cagney wrote: > >This is just a style change. Functionally, it is _exactly_ the same as > >having a makefile fragment. Personally, I prefer the makefile > >fragments. > > As mark noted: > > > >I'm also thinking about the ultimate replacement of the makefile > > >fragments in config/*/. I think we should move towards a configure > > >script where we can use wildcards to set some sensible defaults. > > >There we'd have something like: > > and I have to agree - having to add the same file to all those nat files > sux. Having to regenerate configure to change files also sucks, for instance for tracking the right autoconf version and for distributors who want to create usable patches. Having to deal with an even higher rate of patch fuzz/conflict also sucks. Being able to localize architecture changes to architecture files is, in my opinion, highly desirable. I prefer it as it is. If the GDB developers want to settle on a different style choice than I'll bow to that, but please don't claim that it's a substantive or obvious improvement. > >>>Going forward we need to get GNU/Linux and other systems using procfs > >>>and an obvious migration path for that is to build support for both > >>>procfs and ptrace into a single GDB. The default being to use ptrace. > > > > > >Huh? We don't "need" to do this, and in fact it's not even clearly > >desirable. I don't get where you're coming from. It's also 100% > >orthogonal to this issue. > > Er, linux-nat already contains all sort of [snip] manipulating /proc. > As more features get added we'll be forced to add still more. Shouldn't > we cut our losses? But almost none of those overlap with ptrace. The only one which does is reading of memory. Linux does not have a /proc based debugging interface and no one has expressed willingness to write one. /proc is used to augment ptrace for things like generate-core-file. We can't "get GNU/Linux [...] using procfs". > Why is it orthogonal? If we assume that configure determines when /proc > and ptrace() and provides both to the user it certainly isn't. Idea's > such as Mark's and mine would make it easier. Why is it related? How would this make it easier? It's not hard to add a new backend file to all the Linux targets; it's really not much different in a lot of little files than in one big one. I've done this plenty of times. -- Daniel Jacobowitz