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

[Daniel Jacobowitz <drow at false dot org>]

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