From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23183 invoked by alias); 4 Oct 2004 17:20:52 -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 23174 invoked from network); 4 Oct 2004 17:20:51 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 4 Oct 2004 17:20:51 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id i94HKltO002777; Mon, 4 Oct 2004 19:20:47 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id i94HKlMa001190; Mon, 4 Oct 2004 19:20:47 +0200 (CEST) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id i94HKl66001187; Mon, 4 Oct 2004 19:20:47 +0200 (CEST) Date: Mon, 04 Oct 2004 17:20:00 -0000 Message-Id: <200410041720.i94HKl66001187@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: cagney@gnu.org CC: gdb-patches@sources.redhat.com In-reply-to: <41615D1E.8070007@gnu.org> (message from Andrew Cagney on Mon, 04 Oct 2004 10:24:30 -0400) Subject: Re: [patch/rfc] Build inf-ptrace.o when ptrace available References: <415DC09D.2070407@gnu.org> <200410012154.i91Ls6lE001359@elgar.sibelius.xs4all.nl> <41615D1E.8070007@gnu.org> X-SW-Source: 2004-10/txt/msg00058.txt.bz2 Date: Mon, 04 Oct 2004 10:24:30 -0400 From: Andrew Cagney > Date: Fri, 01 Oct 2004 16:39:57 -0400 > From: Andrew Cagney > > This modifies GDB's configure to build inf-ptrace.o whenever > the ptrace call is available. Thoughts? > > I'm not sure. On the one hand, yes, inf-ptrace should compile & link > on any system that has ptrace. On the other hand, actually using this > stuff is still a per-target decision, and there are quite a few > targets that have ptrace, but dont use it (Solaris, OSF/1, HP-UX). FYI, it isn't _linked_, except on GDB executables that use it. You're right. We still need to compile it though, and it makes libgdb.a bigger. Won't make the build process any faster my Apple Quadra 900, SPARClassic or simulated VAX. So actually I'm opposed to all patches that add unnecessary bloat ;-). > 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: > > *-*-*bsd*) > native_sources="inf-ptrace.c bsd-nat.c" > ;; > > *-*-linux*) > native_sources="inf-ptrace.c linux-nat.c" > ;; 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. The /proc on Linux is not even close to a "real" procfs. Building support for both ptrace(2) and proc(4) is only useful for the OS formerly know as OSF/1. > *-*-solaris*) > native_sources="inf-procfs.c" > ;; > > I'm not strongly opposed to your patch (but you should look at it > again, see the hunk below). I also think that the logic that adds > inf-ptrace.o / inf-ptrace.c doesn't belong in the "Checks for library > functions" section. I'd leave the AC_CHECK_FUNCS(ptrace) there > (possibly grouping it together with the check for ttrace), and put the > rest of the logic somewhere else. Ah. But where? I couldn't find anywhere. Somewhere near the end, like where we set SER_HARDWIRE. Mark