[patch/rfc] Build inf-ptrace.o when ptrace available

[patch/rfc] Build inf-ptrace.o when ptrace available

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 119 bytes --]

Hello,

This modifies GDB's configure to build inf-ptrace.o whenever the ptrace 
call is available.  Thoughts?

Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 8293 bytes --]

2004-10-01  Andrew Cagney  <cagney@gnu.org>

	* configure.in: Check for the function ptrace.  If present, add in
	inf-ptrace.o / inf-ptrace.c.
	* configure, config.in: Re-generate.
	* config/vax/obsd.mh (NATDEPFILES): Remove inf-ptrace.o.
	* config/vax/nbsdelf.mh (NATDEPFILES): Remove inf-ptrace.o.
	* config/vax/nbsdaout.mh (NATDEPFILES): Remove inf-ptrace.o.
	* config/powerpc/nbsd.mh (NATDEPFILES): Remove inf-ptrace.o.
	* config/i386/obsdaout.mh (NATDEPFILES): Remove inf-ptrace.o.
	* config/i386/obsd64.mh (NATDEPFILES): Remove inf-ptrace.o.
	* config/i386/obsd.mh (NATDEPFILES): Remove inf-ptrace.o.
	* config/i386/nbsdelf.mh (NATDEPFILES): Remove inf-ptrace.o.
	* config/i386/nbsdaout.mh (NATDEPFILES): Remove inf-ptrace.o.
	* config/i386/nbsd64.mh (NATDEPFILES): Remove inf-ptrace.o.
	* config/i386/fbsd64.mh (NATDEPFILES): Remove inf-ptrace.o.
	* config/i386/fbsd.mh (NATDEPFILES): Remove inf-ptrace.o.
	
Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.175
diff -p -u -r1.175 configure.in
--- configure.in	28 Sep 2004 20:17:32 -0000	1.175
+++ configure.in	1 Oct 2004 20:34:38 -0000
@@ -469,6 +469,13 @@ AC_CHECK_FUNCS(syscall)
 AC_CHECK_FUNCS(ttrace)
 AC_CHECK_FUNCS(wborder)
 
+# Check for ptrace, and and if present build inf-ptrace.
+AC_CHECK_FUNCS(ptrace)
+if test x"$ac_cv_func_ptrace" = xyes; then
+   CONFIG_OBS="$CONFIG_OBS inf-ptrace.o"
+   CONFIG_SRCS="$CONFIG_SRCS inf-ptrace.c"
+fi
+
 # Check the return and argument types of ptrace.  No canned test for
 # this, so roll our own.
 gdb_ptrace_headers='
@@ -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.
+
+
 dnl AC_FUNC_SETPGRP does not work when cross compiling
 dnl Instead, assume we will have a prototype for setpgrp if cross compiling.
 if test "$cross_compiling" = no; then
Index: config/i386/fbsd.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/fbsd.mh,v
retrieving revision 1.19
diff -p -u -r1.19 fbsd.mh
--- config/i386/fbsd.mh	1 Oct 2004 17:26:12 -0000	1.19
+++ config/i386/fbsd.mh	1 Oct 2004 20:34:39 -0000
@@ -1,5 +1,5 @@
 # Host: FreeBSD/i386
-NATDEPFILES= fork-child.o inf-ptrace.o \
+NATDEPFILES= fork-child.o \
 	fbsd-nat.o i386-nat.o i386bsd-nat.o i386fbsd-nat.o \
 	gcore.o bsd-kvm.o
 NAT_FILE= nm-fbsd.h
Index: config/i386/fbsd64.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/fbsd64.mh,v
retrieving revision 1.11
diff -p -u -r1.11 fbsd64.mh
--- config/i386/fbsd64.mh	1 Oct 2004 17:26:13 -0000	1.11
+++ config/i386/fbsd64.mh	1 Oct 2004 20:34:39 -0000
@@ -1,5 +1,5 @@
 # Host: FreeBSD/amd64
-NATDEPFILES= fork-child.o inf-ptrace.o \
+NATDEPFILES= fork-child.o \
 	fbsd-nat.o amd64-nat.o amd64bsd-nat.o amd64fbsd-nat.o \
 	gcore.o bsd-kvm.o
 
Index: config/i386/nbsd64.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nbsd64.mh,v
retrieving revision 1.7
diff -p -u -r1.7 nbsd64.mh
--- config/i386/nbsd64.mh	1 Oct 2004 17:26:13 -0000	1.7
+++ config/i386/nbsd64.mh	1 Oct 2004 20:34:39 -0000
@@ -1,3 +1,2 @@
 # Host: NetBSD/amd64
-NATDEPFILES= fork-child.o inf-ptrace.o \
-	amd64-nat.o amd64bsd-nat.o amd64nbsd-nat.o
+NATDEPFILES= fork-child.o amd64-nat.o amd64bsd-nat.o amd64nbsd-nat.o
Index: config/i386/nbsdaout.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nbsdaout.mh,v
retrieving revision 1.7
diff -p -u -r1.7 nbsdaout.mh
--- config/i386/nbsdaout.mh	1 Oct 2004 17:26:13 -0000	1.7
+++ config/i386/nbsdaout.mh	1 Oct 2004 20:34:39 -0000
@@ -1,6 +1,5 @@
 # Host: NetBSD/i386 a.out
-NATDEPFILES= fork-child.o inf-ptrace.o \
-	i386bsd-nat.o i386nbsd-nat.o bsd-kvm.o \
+NATDEPFILES= fork-child.o i386bsd-nat.o i386nbsd-nat.o bsd-kvm.o \
 	solib.o solib-sunos.o
 NAT_FILE= nm-nbsdaout.h
 
Index: config/i386/nbsdelf.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nbsdelf.mh,v
retrieving revision 1.21
diff -p -u -r1.21 nbsdelf.mh
--- config/i386/nbsdelf.mh	1 Oct 2004 17:26:13 -0000	1.21
+++ config/i386/nbsdelf.mh	1 Oct 2004 20:34:39 -0000
@@ -1,6 +1,5 @@
 # Host: NetBSD/i386 ELF
-NATDEPFILES= fork-child.o inf-ptrace.o \
-	i386bsd-nat.o i386nbsd-nat.o bsd-kvm.o
+NATDEPFILES= fork-child.o i386bsd-nat.o i386nbsd-nat.o bsd-kvm.o
 NAT_FILE= config/nm-nbsd.h
 
 LOADLIBES= -lkvm
Index: config/i386/obsd.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/obsd.mh,v
retrieving revision 1.13
diff -p -u -r1.13 obsd.mh
--- config/i386/obsd.mh	1 Oct 2004 17:26:13 -0000	1.13
+++ config/i386/obsd.mh	1 Oct 2004 20:34:39 -0000
@@ -1,6 +1,5 @@
 # Host: OpenBSD/i386 ELF
-NATDEPFILES= fork-child.o inf-ptrace.o \
-	i386bsd-nat.o i386obsd-nat.o i386nbsd-nat.o bsd-kvm.o
+NATDEPFILES= fork-child.o i386bsd-nat.o i386obsd-nat.o i386nbsd-nat.o bsd-kvm.o
 NAT_FILE= nm-obsd.h
 
 LOADLIBES= -lkvm
Index: config/i386/obsd64.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/obsd64.mh,v
retrieving revision 1.8
diff -p -u -r1.8 obsd64.mh
--- config/i386/obsd64.mh	1 Oct 2004 17:26:13 -0000	1.8
+++ config/i386/obsd64.mh	1 Oct 2004 20:34:39 -0000
@@ -1,5 +1,4 @@
 # Host: OpenBSD/amd64
-NATDEPFILES= fork-child.o inf-ptrace.o \
-	amd64-nat.o amd64bsd-nat.o amd64obsd-nat.o bsd-kvm.o
+NATDEPFILES= fork-child.o amd64-nat.o amd64bsd-nat.o amd64obsd-nat.o bsd-kvm.o
 
 LOADLIBES= -lkvm
Index: config/i386/obsdaout.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/obsdaout.mh,v
retrieving revision 1.6
diff -p -u -r1.6 obsdaout.mh
--- config/i386/obsdaout.mh	1 Oct 2004 17:26:13 -0000	1.6
+++ config/i386/obsdaout.mh	1 Oct 2004 20:34:39 -0000
@@ -1,5 +1,5 @@
 # Host: OpenBSD/i386 a.out
-NATDEPFILES= fork-child.o inf-ptrace.o \
+NATDEPFILES= fork-child.o \
 	i386bsd-nat.o i386nbsd-nat.o i386obsd-nat.o bsd-kvm.o \
 	solib.o solib-sunos.o
 NAT_FILE= nm-obsd.h
Index: config/powerpc/nbsd.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/powerpc/nbsd.mh,v
retrieving revision 1.15
diff -p -u -r1.15 nbsd.mh
--- config/powerpc/nbsd.mh	1 Oct 2004 17:26:14 -0000	1.15
+++ config/powerpc/nbsd.mh	1 Oct 2004 20:34:39 -0000
@@ -1,5 +1,5 @@
 # Host: PowerPC, running NetBSD
-NATDEPFILES= fork-child.o inf-ptrace.o infptrace.o ppcnbsd-nat.o bsd-kvm.o
+NATDEPFILES= fork-child.o infptrace.o ppcnbsd-nat.o bsd-kvm.o
 NAT_FILE= config/nm-nbsd.h
 
 LOADLIBES= -lkvm
Index: config/vax/nbsdaout.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/vax/nbsdaout.mh,v
retrieving revision 1.4
diff -p -u -r1.4 nbsdaout.mh
--- config/vax/nbsdaout.mh	1 Oct 2004 17:26:14 -0000	1.4
+++ config/vax/nbsdaout.mh	1 Oct 2004 20:34:39 -0000
@@ -1,7 +1,5 @@
 # Host: NetBSD/vax a.out
-NATDEPFILES= fork-child.o inf-ptrace.o \
-	vaxbsd-nat.o bsd-kvm.o \
-	solib.o solib-sunos.o
+NATDEPFILES= fork-child.o vaxbsd-nat.o bsd-kvm.o solib.o solib-sunos.o
 NAT_FILE= nm-nbsdaout.h
 
 LOADLIBES= -lkvm
Index: config/vax/nbsdelf.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/vax/nbsdelf.mh,v
retrieving revision 1.7
diff -p -u -r1.7 nbsdelf.mh
--- config/vax/nbsdelf.mh	1 Oct 2004 17:26:14 -0000	1.7
+++ config/vax/nbsdelf.mh	1 Oct 2004 20:34:39 -0000
@@ -1,5 +1,4 @@
 # Host: NetBSD/vax ELF
-NATDEPFILES= fork-child.o inf-ptrace.o \
-	vaxbsd-nat.o bsd-kvm.o
+NATDEPFILES= fork-child.o vaxbsd-nat.o bsd-kvm.o
 
 LOADLIBES= -lkvm
Index: config/vax/obsd.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/vax/obsd.mh,v
retrieving revision 1.5
diff -p -u -r1.5 obsd.mh
--- config/vax/obsd.mh	1 Oct 2004 17:26:14 -0000	1.5
+++ config/vax/obsd.mh	1 Oct 2004 20:34:39 -0000
@@ -1,5 +1,4 @@
 # Host: OpenBSD/vax
-NATDEPFILES= fork-child.o inf-ptrace.o \
-	vaxbsd-nat.o bsd-kvm.o
+NATDEPFILES= fork-child.o vaxbsd-nat.o bsd-kvm.o
 
 LOADLIBES= -lkvm

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Mark Kettenis]

   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).

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"
  ;;

*-*-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.

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.
   +
   +
    dnl AC_FUNC_SETPGRP does not work when cross compiling
    dnl Instead, assume we will have a prototype for setpgrp if cross compiling.
    if test "$cross_compiling" = no; then

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Daniel Jacobowitz]

On Fri, Oct 01, 2004 at 04:39:57PM -0400, Andrew Cagney wrote:
> Hello,
> 
> This modifies GDB's configure to build inf-ptrace.o whenever the ptrace 
> call is available.  Thoughts?

I think this only makes sense as part of the removal of NATDEPFILES,
and that it doesn't make sense without the context of how you plan to
remove the other members of NATDEPFILES.  Since we're still going to
need a way to specify the native configuration files, why bother?

-- 
Daniel Jacobowitz

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Andrew Cagney]

>    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.

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Andrew Cagney]

> On Fri, Oct 01, 2004 at 04:39:57PM -0400, Andrew Cagney wrote:
> 
>>> Hello,
>>> 
>>> This modifies GDB's configure to build inf-ptrace.o whenever the ptrace 
>>> call is available.  Thoughts?
> 
> 
> I think this only makes sense as part of the removal of NATDEPFILES,
> and that it doesn't make sense without the context of how you plan to
> remove the other members of NATDEPFILES.  Since we're still going to
> need a way to specify the native configuration files, why bother?

See Mark's e-mail (and it is easier than remembering which NATDEPFILES 
need it).

Andrew

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Daniel Jacobowitz]

On Mon, Oct 04, 2004 at 10:24:30AM -0400, Andrew Cagney wrote:
> >   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"
> >  ;;

This is just a style change.  Functionally, it is _exactly_ the same as
having a makefile fragment.  Personally, I prefer the makefile
fragments.

> 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.

Huh?  We don't "need" to do this, and in fact it's not even clearly
desirable.  I don't get where you're coming from.  It's also 100%
orthogonal to this issue.

-- 
Daniel Jacobowitz

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Daniel Jacobowitz]

On Mon, Oct 04, 2004 at 10:31:01AM -0400, Andrew Cagney wrote:
> >On Fri, Oct 01, 2004 at 04:39:57PM -0400, Andrew Cagney wrote:
> >
> >>>Hello,
> >>>
> >>>This modifies GDB's configure to build inf-ptrace.o whenever the ptrace 
> >>>call is available.  Thoughts?
> >
> >
> >I think this only makes sense as part of the removal of NATDEPFILES,
> >and that it doesn't make sense without the context of how you plan to
> >remove the other members of NATDEPFILES.  Since we're still going to
> >need a way to specify the native configuration files, why bother?
> 
> See Mark's e-mail (and it is easier than remembering which NATDEPFILES 
> need it).

I think that's a non-issue.  You don't need to remember it - either
it's there or it isn't.

-- 
Daniel Jacobowitz

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Andrew Cagney]

> On Mon, Oct 04, 2004 at 10:31:01AM -0400, Andrew Cagney wrote:
> 
>>>> >On Fri, Oct 01, 2004 at 04:39:57PM -0400, Andrew Cagney wrote:
>>>> >
>>>
>>>>>> >>>Hello,
>>>>>> >>>
>>>>>> >>>This modifies GDB's configure to build inf-ptrace.o whenever the ptrace 
>>>>>> >>>call is available.  Thoughts?
>>>
>>>> >
>>>> >
>>>> >I think this only makes sense as part of the removal of NATDEPFILES,
>>>> >and that it doesn't make sense without the context of how you plan to
>>>> >remove the other members of NATDEPFILES.  Since we're still going to
>>>> >need a way to specify the native configuration files, why bother?
>>
>>> 
>>> See Mark's e-mail (and it is easier than remembering which NATDEPFILES 
>>> need it).
> 
> 
> I think that's a non-issue.  You don't need to remember it - either
> it's there or it isn't.

It is, when you're the one trying to keep track of all the *.nm files 
and their systems as they get migrated to inf-ptrace.

Andrew

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Andrew Cagney]

> On Mon, Oct 04, 2004 at 10:24:30AM -0400, Andrew Cagney wrote:
> 
>>>> >   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"
>>>> >  ;;
> 
> 
> This is just a style change.  Functionally, it is _exactly_ the same as
> having a makefile fragment.  Personally, I prefer the makefile
> fragments.

As mark noted:

 > >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:

and I have to agree - having to add the same file to all those nat files 
sux.

>>> 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.
> 
> 
> Huh?  We don't "need" to do this, and in fact it's not even clearly
> desirable.  I don't get where you're coming from.  It's also 100%
> orthogonal to this issue.

Er, linux-nat already contains all sort of [snip] manipulating /proc. 
As more features get added we'll be forced to add still more.  Shouldn't 
we cut our losses?

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.

Andrew

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Daniel Jacobowitz]

On Mon, Oct 04, 2004 at 12:27:10PM -0400, Andrew Cagney wrote:
> >This is just a style change.  Functionally, it is _exactly_ the same as
> >having a makefile fragment.  Personally, I prefer the makefile
> >fragments.
> 
> As mark noted:
> 
> > >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:
> 
> and I have to agree - having to add the same file to all those nat files 
> sux.

Having to regenerate configure to change files also sucks, for instance
for tracking the right autoconf version and for distributors who want
to create usable patches.  Having to deal with an even higher rate of
patch fuzz/conflict also sucks.  Being able to localize architecture
changes to architecture files is, in my opinion, highly desirable.  I
prefer it as it is.  If the GDB developers want to settle on a
different style choice than I'll bow to that, but please don't claim
that it's a substantive or obvious improvement.

> >>>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.
> >
> >
> >Huh?  We don't "need" to do this, and in fact it's not even clearly
> >desirable.  I don't get where you're coming from.  It's also 100%
> >orthogonal to this issue.
> 
> Er, linux-nat already contains all sort of [snip] manipulating /proc. 
> As more features get added we'll be forced to add still more.  Shouldn't 
> we cut our losses?

But almost none of those overlap with ptrace.  The only one which does
is reading of memory.  Linux does not have a /proc based debugging
interface and no one has expressed willingness to write one.  /proc is
used to augment ptrace for things like generate-core-file.  We can't
"get GNU/Linux [...] using procfs".

> 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.

-- 
Daniel Jacobowitz

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Mark Kettenis]

   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

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Andrew Cagney]

>    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.

Fortunatly, that can be fixed (just like any other kernel bug - we've 
been seeing success in that area recently ;-).

Andrew

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Mark Kettenis]

   Date: Mon, 04 Oct 2004 13:51:17 -0400
   From: Andrew Cagney <cagney@gnu.org>

   >    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.

   Fortunatly, that can be fixed (just like any other kernel bug - we've 
   been seeing success in that area recently ;-).

You know Andrew, you can be really funny ;-).

Mark

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Andrew Cagney]

> We can't "get GNU/Linux [...] using procfs".

Is there a technical problem blocking this?

>>> 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 ...

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.

Andrew

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Daniel Jacobowitz]

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

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Andrew Cagney]

> 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.

The're not.

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Andrew Cagney]

> 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.

So you're not objecting to changes making configure (actually 
configure.host and configure.tgt) directly handle what was previously in 
the .mh file ...

> 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.

..  but rather just objecting to having inf-ptrace selected dependant on 
autoconf magic?  I could equally hardwire it vis:

case $host in
   *-linux* | *-bsd* ) objs += inf-ptrace
esac

Can you show us the money here - on what systems did you encounter 
problems and what problems were they?

The most recent problem I can think of was with the TUI, and that was a 
straight configure.in bug.

>>>>>> >>>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.

So initially we can migrate things to configure.host, and then, if 
things prove to unwieldly, look at refactoring it.  But not before.

Andrew

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Daniel Jacobowitz]

On Mon, Oct 11, 2004 at 01:23:56PM -0400, Andrew Cagney wrote:
> >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.
> 
> So you're not objecting to changes making configure (actually 
> configure.host and configure.tgt) directly handle what was previously in 
> the .mh file ...

I thought I was being quite clear.  You've presented two suggestions:
  - use autoconf to build inf-ptrace
  - goal: move natfiles into lists in the configure scripts

I've said that I object to them both.  I object strongly to the first,
and stylisticly to the second.

> >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.
> 
> ..  but rather just objecting to having inf-ptrace selected dependant on 
> autoconf magic?  I could equally hardwire it vis:
> 
> case $host in
>   *-linux* | *-bsd* ) objs += inf-ptrace
> esac
> 
> Can you show us the money here - on what systems did you encounter 
> problems and what problems were they?
> 
> The most recent problem I can think of was with the TUI, and that was a 
> straight configure.in bug.

I wrote that my experience with automated builds suggested that a
problem _would_ occur.  I don't have an example of this problem
occuring, but I don't think we need one to understand why it is an
unsound design principle.  The change would cause inf-ptrace to be
built on more systems/configurations (where GDB wouldn't know how to
use it), and could potentially cause it to be built on fewer systems
(where GDB wouldn't work without it).  No win.

> >>>>>>>>>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.
> 
> So initially we can migrate things to configure.host, and then, if 
> things prove to unwieldly, look at refactoring it.  But not before.

So move everything out of makefile fragments before considering
refactoring the makefile fragments?  That doesn't make any sense.

I will continue to object when you present this as a change with valid
technical/maintenance advantages.  If other maintainers agree that it
has better style, I won't object to making the change, I've already
said that.  But I don't want to make a gratuituous change in style for
bogus technical reasons.  Something which can obviously be done in the
current system is not a valid technical reason to discard the current
system.

-- 
Daniel Jacobowitz

Re: [patch/rfc] Build inf-ptrace.o when ptrace available

[Mark Kettenis]

   Date: Wed, 13 Oct 2004 09:54:05 -0400
   From: Daniel Jacobowitz <drow@false.org>

   I wrote that my experience with automated builds suggested that a
   problem _would_ occur.  I don't have an example of this problem
   occuring, but I don't think we need one to understand why it is an
   unsound design principle.  The change would cause inf-ptrace to be
   built on more systems/configurations (where GDB wouldn't know how to
   use it), and could potentially cause it to be built on fewer systems
   (where GDB wouldn't work without it).  No win.

We should try to make things as robust as possible.  In many cases
autoconfiguring makes things more robust than hardcoding things based
on a host triplet.  In some cases this may not be the case though, and
I think inf-ptrace is such a case.

   > >>>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.

Configure-frobbing still gives you more flexibility since it's easier
to change things without having to touch multiple files.  With
makefile-fragmenting, we'd need to modify the configure script in many
cases anyway.  Moreover, configure-frobbing gives you the full
flexibility of the shell syntax.  In a configure.host file for example
I could write things as:

case $host in
  *-openbsd*)
    if test -f $srcdir/${cpu}obsd-nat.c; then
      OBJS += ${cpu}obsd-nat.o
    elif test -f $srcdir/${cpu}nbsd-nat.c; then
      OBJS += ${cpu}nbsd-nat.o
    fi
esac

This could potentially save us quite a substantial number of makefile
fragments.

However, makefile-fragmenting has benefits.  Configure-frobbing can do
variable substition in makefiles, but not much more.
Makefile-fragmenting can use the full makefile syntax.

I'm not sure yet what we need most.  But if our makefile fragments
only contain a list of object files, I'd certainly ditch them in
favour of configure-frobbing.