Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@gnu.org>
To: drow@false.org
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] Use target vector inheritance for GNU/Linux
Date: Mon, 06 Dec 2004 14:41:00 -0000	[thread overview]
Message-ID: <200412061410.iB6EAgpA019134@juw15.nfra.nl> (raw)
In-Reply-To: <20041205184549.GA19814@nevyn.them.org> (message from Daniel Jacobowitz on Sun, 5 Dec 2004 13:45:50 -0500)

   Date: Sun, 5 Dec 2004 13:45:50 -0500
   From: Daniel Jacobowitz <drow@false.org>

   This patch converts all GNU/Linux targets to inf-ptrace.c and target vector
   inheritance.  I was going to do them one at a time, but because the common
   native-specific code is so large for GNU/Linux, it was too awkward.

Daniel, thanks for attacking this.

   A new function, linux_target, is added to linux-nat.c.  Then any GNU/Linux
   target can call it, and pass the result to add_target - after specializing
   whatever methods it needs to.  Sometimes it's necessary to specialize a
   method between inf_ptrace_target and linux_target, so it accepts an optional
   argument.

Yes, indeed, in particual the way the various Linux ports deal with
reading and writing registers is really different.

   This wouldn't be necessary if all target methods took a
   target_ops parameter, so they could call the overridden method.

I don't think so.  The target_ops parameter is intended to provide a
way for strata to "inherit" stuff from other strata (i.e. the
core_stratum inheriting the to_xfer_partial method from the
file_stratum).  Here we're talking about inheriting stuff from a
prototype vector within a single stratum.

   One use of deprecated_child_ops was particularly thorny, so I updated the
   to_follow_fork method to take a struct target_ops and push the correct
   target.  I made to_follow_fork a non-inherited method, like to_xfer_partial.

The comment just above target.c:update_current_target() suggests that
this is a step in the right direction.

   This patch leaves some completely dead macros in config/nm-linux.h, and some
   mostly-but-not-quite dead macros in various other nm-files.  I'll be back.
   I didn't want to change more than absolutely necessary, once I was committed
   to doing all targets.  My next step will be merging the two target vectors
   in linux-nat.c.

   I've tested this patch with the full testsuite on x86_64-linux and
   i386-linux, partial testsuite on ia64-linux [it gets hung up in an
   infinite loop in sigaltstack.exp with or without the patch], and smoke
   testing on s390x [the machine I was using didn't have expect].

I'll try to test & cleanup sparc and possibly sparc64.

   Comments?  Proofreading?  I'm going to let this sit for a couple of days,
   because (while mechanical) it's very large - I think I got everything, but
   since I don't have the resources to test on every single GNU/Linux native
   target, I can't be sure.

I'm just wondering whether the saved_xxx variables should be called
linux_saved_xxx instead.  Probably not...

Mark


  reply	other threads:[~2004-12-06 14:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-05 18:48 Daniel Jacobowitz
2004-12-06 14:41 ` Mark Kettenis [this message]
2004-12-06 14:43   ` Daniel Jacobowitz
2004-12-12 17:53 ` Andrew Cagney
2004-12-12 17:59 ` Andrew Cagney
2004-12-12 21:45   ` Mark Kettenis
2004-12-13 20:45     ` Andrew Cagney
2004-12-13 22:29       ` Mark Kettenis
2004-12-13 22:57         ` Andrew Cagney
2004-12-14  2:06           ` Mark Kettenis
2004-12-14 15:41             ` Andrew Cagney
2004-12-15  0:07               ` Mark Kettenis

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=200412061410.iB6EAgpA019134@juw15.nfra.nl \
    --to=kettenis@gnu.org \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    /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