Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@gnu.org>
To: cagney@gnu.org
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] Build inf-ptrace.o when ptrace available
Date: Mon, 04 Oct 2004 17:20:00 -0000	[thread overview]
Message-ID: <200410041720.i94HKl66001187@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <41615D1E.8070007@gnu.org> (message from Andrew Cagney on Mon, 04 Oct 2004 10:24:30 -0400)

   Date: Mon, 04 Oct 2004 10:24:30 -0400
   From: Andrew Cagney <cagney@gnu.org>

   >    Date: Fri, 01 Oct 2004 16:39:57 -0400
   >    From: Andrew Cagney <cagney@gnu.org>
   > 
   >    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


  parent reply	other threads:[~2004-10-04 17:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-01 20:40 Andrew Cagney
2004-10-01 21:54 ` Mark Kettenis
2004-10-04 14:24   ` Andrew Cagney
2004-10-04 14:34     ` Daniel Jacobowitz
2004-10-04 16:27       ` Andrew Cagney
2004-10-04 16:35         ` Daniel Jacobowitz
2004-10-05 22:44           ` Andrew Cagney
2004-10-05 22:59             ` Daniel Jacobowitz
2004-10-05 23:42               ` Andrew Cagney
2004-10-11 17:24               ` Andrew Cagney
2004-10-13 13:54                 ` Daniel Jacobowitz
2004-10-14 17:14                   ` Mark Kettenis
2004-10-04 17:20     ` Mark Kettenis [this message]
2004-10-04 17:51       ` Andrew Cagney
2004-10-04 18:23         ` Mark Kettenis
2004-10-03 14:50 ` Daniel Jacobowitz
2004-10-04 14:31   ` Andrew Cagney
2004-10-04 14:34     ` Daniel Jacobowitz
2004-10-04 16:18       ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200410041720.i94HKl66001187@elgar.sibelius.xs4all.nl \
    --to=kettenis@gnu.org \
    --cc=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox