From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15035 invoked by alias); 5 Oct 2004 22:59:34 -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 15004 invoked from network); 5 Oct 2004 22:59:31 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 5 Oct 2004 22:59:31 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CEyH5-0007Uu-FE; Tue, 05 Oct 2004 18:59:15 -0400 Date: Tue, 05 Oct 2004 22:59: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: <20041005225914.GA28588@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> <20041004163533.GA12898@nevyn.them.org> <416323A7.2010201@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416323A7.2010201@gnu.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-10/txt/msg00101.txt.bz2 On Tue, Oct 05, 2004 at 06:43:51PM -0400, Andrew Cagney wrote: > >We can't "get GNU/Linux [...] using procfs". > > Is there a technical problem blocking this? The fact that the idea has been "under discussion but no one cares enough to devote two months of programming to it" for at least three years now? The fact that there's no obvious user-visible improvement associated with the huge amount of kernel-side work involved? I think those are technical problems. This, however, is hugely off-topic for the original patch. I still do not believe that configure testing should be used for this purpose. If we end up moving the knowledge of natfiles into configure, then we can set inf-ptrace to be included for all native GNU/Linux targets easily enough. Or there are other ways to do it, as below. One of the reasons why I hold this position is that it lets us give a more useful error message if someone's system is broken and can not compile inf-ptrace.c for some reason that the configure script detected. They'll get either a link failure or a GDB which can't debug anything, instead of an error related to the compile problem. My experience with automating distribution builds tells me that someone will come up with a way to break their system in this fashion. > >>>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. > > If we used configure.tgt and: > switch "$target" > *-*-linux* ) "objs=objs symfile-mem.c" > esac > then all GNU/Linux systems will always and consistently include > symtab-mem.c. We don't, they don't ... This is no harder than having a common linux.mh, as GCC has done for years (gcc/config/t-linux). It's not a technical differece between configure-frobbing and makefile-fragmenting. > We've already got configure.tgt checking OSABI and configure.host > checking FLOATFORMAT so there's plenty of prior art. Further, > modifying/merging just that file is going to be a lot easier than > modifying/merging all the individual *.mh files. I already said that I disagree with your "further". -- Daniel Jacobowitz