This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch/rfc] Build inf-ptrace.o when ptrace available
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