Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH RFC] solib-svr4 cleanups
Date: Mon, 05 Mar 2001 08:11:00 -0000	[thread overview]
Message-ID: <3AA2794F.9ADC0E92@cygnus.com> (raw)
In-Reply-To: <1010302200140.ZM22868@ocotillo.lan>

> Here's how it'll work.  In your (already multiarched) -tdep.c file,
> you'll include solib-svr4.h.  You'll also define a function which'll
> fill in and return a pointer to a link_map_offsets struct.  (See
> sh_link_svr4_fetch_link_map_offsets in sh-tdep.c for an example. 

Just a heads up here for people other then Kevin :-)

I think the ..._offsets() mechanism is pretty generic.  I'm sure there
are other parts of GDB that, at present, drag in native header files to
obtain descriptions of target data structures.  If someone indicates a
desire to fix one of these other parts then generalizing svr4's ofset
mechanism would most likely be a part of that.

(footnote: target is the system being debugged; native is the host as a
target; host is the system that GDB is running on; build is the system
that gdb was built on)  

> Anyway...  I'm not very good at choosing names for new files, so I
> thought I'd let folks comment on my filename choice before committing
> it.  If you have objections to the name that I've chosen (that 8.3
> problem comes to mind), please suggest a meaningful alternative.

Moving it to a separate file is definitly a good move.  As for a name,
what about a more general tbd-*.c (to be deleted)?  There are other
files with the same problem and I'm sure the maintainers would pounce on
the oportunity to boot their legacy code into another file :-)

Anyway, a slightly more tangental thought. You might consider massaging
some of that code into an internal consistency check.  For select native
configs, it would verify the value of the link map supplied by the
target.  I say select because it wouldn't work on a native GDB capable
of debugging more than one executable (eg SPARC 32 and 64).

	Andrew

PS:

Suggest writing

+  if (legacy_svr4_fetch_link_map_offsets_hook)
+    return legacy_svr4_fetch_link_map_offsets_hook ();
+  else

as just

	if (....)
	   return ...

	....

that way, when the legacy code gets deleted the file doesn't need to be
re-indented :-)


  reply	other threads:[~2001-03-05  8:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-02 12:01 Kevin Buettner
2001-03-05  8:11 ` Andrew Cagney [this message]
     [not found]   ` <ac131313@cygnus.com>
2001-03-05 16:20     ` Kevin Buettner
2001-03-05 17:16       ` Kevin Buettner
2001-03-06  0:48       ` Eli Zaretskii
2001-03-06 15:01       ` Andrew Cagney
2001-03-09 22:31 ` Kevin Buettner
2001-03-12 11:46   ` Michael Snyder
2001-03-12 11:55     ` Kevin Buettner
2001-03-12 15:40       ` Michael Snyder

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=3AA2794F.9ADC0E92@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kevinb@cygnus.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