This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Patching gdb 5.0 for XFree86 module support
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: Patching gdb 5.0 for XFree86 module support
- From: "Mike A. Harris" <mharris at redhat dot com>
- Date: Thu, 4 Oct 2001 02:51:38 -0400 (EDT)
- cc: <gdb-patches at sources dot redhat dot com>
- Organization: Red Hat Inc.
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