Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Andrew Cagney <cagney@gnu.org>
Cc: Mark Kettenis <kettenis@gnu.org>, gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] Build inf-ptrace.o when ptrace available
Date: Mon, 04 Oct 2004 16:35:00 -0000	[thread overview]
Message-ID: <20041004163533.GA12898@nevyn.them.org> (raw)
In-Reply-To: <416179DE.70401@gnu.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


  reply	other threads:[~2004-10-04 16:35 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 [this message]
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=20041004163533.GA12898@nevyn.them.org \
    --to=drow@false.org \
    --cc=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