Patching gdb 5.0 for XFree86 module support

["Mike A. Harris" <mharris@redhat.com>]

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.

My goal is to get this patch sync'd with current gdb that will 
ship with the next version of Red Hat Linux, and provide it on 
ftp://people.redhat.com/mharris and elsewhere for people to snag 
a copy.

When I started this the other day, I had never looked at gdb 
source before, so bear with me.  ;o)

I first ported the patch to at least apply cleanly to current
source, making some guesses along the way when not 100% sure what
was correct.  I've fixed all compilation warnings and all
compilation errors but one now, which I'm not yet sure how to
resolve as I'm not too familiar with gdb internals.

gcc -c -O2 -march=i386 -mcpu=i686 -DXFREE_MODULE_SUPPORT    -I. 
-I. -I./config -DHAVE_CONFIG_H -I./../include/opcode 
-I./../readline/.. -I../bfd -I./../bfd  -I./../include -I../intl 
-I./../intl  -DMI_OUT=1 -DUI_OUT=1 -Wimplicit -Wreturn-type 
-Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith 
-Wuninitialized  xfreemod.c
xfreemod.c: In function `module_add_stub':
xfreemod.c:241: too many arguments to function `symbol_file_add'
make[1]: *** [xfreemod.o] Error 1
make[1]: Leaving directory 
`/home/mharris/rpmbuild/BUILD/gdb+dejagnu-20010813/gdb'
make: *** [all-gdb] Error 2
Bad exit status from /home/mharris/rpmbuild/tmp/rpm-tmp.60784 
(%build)

For those willing to help, or offer advice, I've put my SRPM at:

ftp://people.redhat.com/mharris/hacks/gdb-5.0rh-15.4xfree.src.rpm

The patch is also attached to this message as well, and contains 
further comments on my progress, etc.

I'd be greatful for any suggestions anyone may have that help get
this working.  Also, what is the best list for such discussion?

Thanks in advance for any help.


----------------------------------------------------------------------
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
From kettenis@science.uva.nl Sun Sep 23 06:33:00 2001
From: Mark Kettenis <kettenis@science.uva.nl>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfc/patch] extract/store typed floating ()
Date: Sun, 23 Sep 2001 06:33:00 -0000
Message-id: <s3i7kuqc9u5.fsf@soliton.wins.uva.nl>
References: <3BAA6F4A.1000508@cygnus.com>
X-SW-Source: 2001-09/msg00307.html
Content-length: 1389

Andrew Cagney <ac131313@cygnus.com> writes:

> Hello,
> 
> This patch introduces two new functions:
> 
> 	extract_typed_floating()
> 	store_typed_floating()
> 
> The new functions take a ``struct type'' that exactly describes the 
> floating point number to be extracted / stored.

The new names sound a lot better than the extract_doublest() you
proposed earlier.  I'd say, go for it :-).

> Assuming that there are no concerns raised, I'll check this in in a few 
> days.

I'm not sure whether zeroing out the buffer in store_typed_floating()
is desirable.  I've (almost) convinced myself that it isn't.  Here's a
part of a comment that I added to the doublest.c in my current tree:

      /* ...

         It is debatable whether we should zero out any remaining
         bytes in the target buffer, when converting from a type that
         has a smaller length than the target type.  Right now we
         don't do that.  A typical case where this situation arises is
         when we convert a i387 floating-point register to a `long
         double' in memory.  On the target, that operation only stores
         the first 10 bytes, and leaves alone the remaining 2 bytes.
         It makes sense to mimick this behaviour here.  */

This comment comes from a function convert_floating() that I intend to
add to doublest.c.  I'll submit a patch after you've checked yours in.

Mark