Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Mike A. Harris" <mharris@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: <gdb-patches@sources.redhat.com>
Subject: Re: Patching gdb 5.0 for XFree86 module support
Date: Wed, 03 Oct 2001 23:51:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.33.0110040247390.9422-100000@devserv.devel.redhat.com> (raw)
In-Reply-To: <3BAEBF5A.4090209@cygnus.com>

On Mon, 24 Sep 2001, Andrew Cagney wrote:

>> I've been working the last few days on porting an older gdb 
>> 4.18 patch that adds support to gdb for debugging XFree86 
>> loadable modules in place without requiring a static server 
>> build.  This has several advantages for an XFree86 developer, as 
>> well as for the more technical user out there who is capable of 
>> debugging a problem, but not necessarily willing or capable to 
>> rebuild XFree86 from source as a static server.
>
>Just FYI, shared library support in current GDB is very different to 
>that found in 5.0.  It was overhalled and made far far more modular.

Cool.  So it sounds like doing this might be simpler than I
initially anticipated?

Should I grab a copy of the gdb head CVS, or a particular tag?  
Also, can you point me to the CVS info for gdb?

>Looking at this patch and especially the comment:
>
>>> +/* The XFree server has its own dynamic load mechanism. Unlike shared
>>> + * libraries it loads regular .o (or even .a) files. GDB support for
>>> + * tracking loaded modules is very similar to shared libraries however
>>> + * (in fact much of this code originated in solib.c).
>>> + *
>>> + * There are a few differences. We don't need to do very much in the
>>> + * create_inferior hook as no modules are loaded at that point so we
>>> + * just tidy up after the last run, tell the inferior that we're
>>> + * around and insert a breakpoint so we get chance to do something
>>> + * when a module is loaded.
>>> + *
>>> + */
>
>the basic idea is sound.  Per Daniel J's comment several people have 
>proposed similar things while makig the observation that the current 
>shlib implementation should be generalized.

Makes sense.  How complex a task to you think that would be?

>PS: Since the patch is very old, I'll just add a heads up that I'll need 
>to run the usual checks.

Cool, thanks.



----------------------------------------------------------------------
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
General open IRC discussion:    #xfree86 on irc.openprojects.org
----------------------------------------------------------------------
root@dod.usarmy.gov:~#  rm -f /bin/laden


      parent reply	other threads:[~2001-10-03 23:51 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
2001-10-03 23:51   ` Mike A. Harris [this message]

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.0110040247390.9422-100000@devserv.devel.redhat.com \
    --to=mharris@redhat.com \
    --cc=ac131313@cygnus.com \
    --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