Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Mike A. Harris" <mharris@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, <gdb-patches@sources.redhat.com>
Subject: Re: Patching gdb 5.0 for XFree86 module support
Date: Tue, 25 Sep 2001 16:19:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.33.0109251813590.31577-100000@devserv.devel.redhat.com> (raw)
In-Reply-To: <1010925174228.ZM31980@ocotillo.lan>

On Tue, 25 Sep 2001, Kevin Buettner wrote:

>> ... proposed similar things while making the observation that the current 
>> shlib implementation should be generalized.
>
>I've been giving this a bit of thought.  Until now, it never occurred
>to me that we'd want more than one shared library symbol loader active
>simultaneously.  For this kind of scenario (non-system library loaders),
>I think it would be beneficial to extend GDB's shared lib machinery.
>
>Once this is done, support for the XFree86 loader will be possible
>without needing to introduce a new breakpoint type.  The changes to
>infrun.c will also become unnecessary.

Cool.

>As to how to extend the solib machinery...
>
>It seems to me that current_target_so_ops could be changed to point at
>a chain of target_so_ops structs.  Each of the TARGET_SO_* macros
>would be rewritten as functions to invoke the relevant method for each
>backend in the chain.  For methods which return values, the
>TARGET_SO_* replacement functions would need to construct an
>appropriate aggragate return value.  (This is probably not as hard as
>it sounds; e.g, TARGET_SO_IN_DYNSYM_RESOLVE_CODE would call the
>in_dynsym_resolve_code method for each backend and return 1 (true) if
>any of the backend code returned true.  The only moderately tricky one
>would be TARGET_SO_CURRENT_SOS(), but I don't see any great difficulty
>with making this one work either.)

A bit over my head, but I think I follow what you're saying as 
far as understanding what it will do - but not how to implement 
it.

I'm not at all familiar with gdb source, and only took the old 
patch and munged it one hunk at a time to fit into gdb 5.  
Certain portions didn't make sense and wouldn't 'fit' so to 
speak, so I analyzed the code by hand in each case as best as I 
could, and massaged it to fit appropriately, at least that was 
the aim.  Then fixed up numerous compiler errors, and warnings.

IOW -> I code monkey'd it into working.  I'm still not familiar 
enough with all the internals of gdb to fully grok what needs to 
change for it to work properly out of the box.  Ultimately of 
course, I would love to see a generic solution that is integrated 
into gdb and just 'works' with XFree86 as well.  Depending on how 
complex that would be to do though, I'd settle for a quick hack 
ontop of a hack on a hack though that "works for now(tm)".  ;o)

Your help is thus muchly appreciated,
Thanks.

TTYL

----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
XFree86 maintainer              Ontario, Canada, P6C 5B3
Red Hat Inc.                    Phone: (705)949-2136
http://www.redhat.com           ftp://people.redhat.com/mharris

Red Hat XFree86 mailing list:   xfree86-list@redhat.com
IRC:  #redhat-xfree86 on irc.openprojects.org
----------------------------------------------------------------------
root@dod.usarmy.gov:~#  rm -f /bin/laden


  reply	other threads:[~2001-09-25 16:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-23  6:27 Mike A. Harris
2001-09-23 10:42 ` Daniel Jacobowitz
2001-09-25 10:52   ` Kevin Buettner
2001-10-03 23:45     ` Mike A. Harris
     [not found] ` <3BAEBF5A.4090209@cygnus.com>
2001-09-23 22:20   ` Mike A. Harris
2001-09-25 10:42   ` Kevin Buettner
2001-09-25 16:19     ` Mike A. Harris [this message]
2001-10-03 23:51   ` Mike A. Harris

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=Pine.LNX.4.33.0109251813590.31577-100000@devserv.devel.redhat.com \
    --to=mharris@redhat.com \
    --cc=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