From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mike A. Harris" To: Subject: Patching gdb 5.0 for XFree86 module support Date: Sun, 23 Sep 2001 06:27:00 -0000 Message-id: X-SW-Source: 2001-09/msg00306.html 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 To: Andrew Cagney 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: References: <3BAA6F4A.1000508@cygnus.com> X-SW-Source: 2001-09/msg00307.html Content-length: 1389 Andrew Cagney 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