From: Andrew Cagney <cagney@gnu.org>
To: Mark Kettenis <kettenis@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] Build inf-ptrace.o when ptrace available
Date: Mon, 04 Oct 2004 14:24:00 -0000 [thread overview]
Message-ID: <41615D1E.8070007@gnu.org> (raw)
In-Reply-To: <200410012154.i91Ls6lE001359@elgar.sibelius.xs4all.nl>
> Date: Fri, 01 Oct 2004 16:39:57 -0400
> From: Andrew Cagney <cagney@gnu.org>
>
> Hello,
>
> 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.
> 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.
> *-*-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.
> Mark
>
>
> @@ -532,6 +539,9 @@ if test -n "$[5]"; then
> [Define to the type of arg 5 for ptrace.])
> fi
>
> +dnl If there is ptrace, add inf-ptrace to the compile list.
> +
> +
Oops.
next prev parent reply other threads:[~2004-10-04 14:24 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 [this message]
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
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=41615D1E.8070007@gnu.org \
--to=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@gnu.org \
/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