Patching gdb 5.0 for XFree86 module support

Patching gdb 5.0 for XFree86 module support

[Mike A. Harris]

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

Re: Patching gdb 5.0 for XFree86 module support

[Daniel Jacobowitz]

On Sun, Sep 23, 2001 at 09:27:00AM -0400, Mike A. Harris wrote:
> 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.

Well, I don't know the solution to that problem off hand, but here's
comments on two things that jumped out at me.

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

Right here.

> --- gdb/dbxread.c.xfree86-modules	Sat Jul  7 13:19:50 2001
> +++ gdb/dbxread.c	Sun Sep 23 07:53:12 2001
> @@ -2272,7 +2272,7 @@
>  	    case 'F':
>  	      function_stab_type = type;
>  
> -#ifdef SOFUN_ADDRESS_MAYBE_MISSING
> +#if defined(SOFUN_ADDRESS_MAYBE_MISSING) || defined(XFREE_MODULE_SUPPORT)
>  	      /* Deal with the SunPRO 3.0 compiler which omits the address
>  	         from N_FUN symbols.  */
>  	      if (type == N_FUN

I'm not sure that's going to fly.  SOFUN_ADDRESS_MAYBE_MISSING
introduces its own problems; there's a good discussion in the list
archives but I can't find it at the moment.  Of course, I can see why
you'd need that segment.

> --- gdb/xfreemod.c.xfree86-modules	Sun Sep 23 07:53:12 2001
> +++ gdb/xfreemod.c	Sun Sep 23 08:01:57 2001

> +/* 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.
> + *
> + */

Actually, CREATE_INFERIOR_HOOK seems to be called during remote attach. 
I'm not absolutely convinced that it should be, but it is - see
remote.c (might post-date your RPM, I'm not sure).  So this assumption
may not be valid.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Patching gdb 5.0 for XFree86 module support

[Kevin Buettner]

On Sep 24,  1:06am, Andrew Cagney 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.

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.)

Kevin

Re: Patching gdb 5.0 for XFree86 module support

[Kevin Buettner]

On Sep 23,  1:42pm, Daniel Jacobowitz wrote:

> > --- gdb/dbxread.c.xfree86-modules	Sat Jul  7 13:19:50 2001
> > +++ gdb/dbxread.c	Sun Sep 23 07:53:12 2001
> > @@ -2272,7 +2272,7 @@
> >  	    case 'F':
> >  	      function_stab_type = type;
> >  
> > -#ifdef SOFUN_ADDRESS_MAYBE_MISSING
> > +#if defined(SOFUN_ADDRESS_MAYBE_MISSING) || defined(XFREE_MODULE_SUPPORT)
> >  	      /* Deal with the SunPRO 3.0 compiler which omits the address
> >  	         from N_FUN symbols.  */
> >  	      if (type == N_FUN
> 
> I'm not sure that's going to fly.  SOFUN_ADDRESS_MAYBE_MISSING
> introduces its own problems; there's a good discussion in the list
> archives but I can't find it at the moment.  Of course, I can see why
> you'd need that segment.

I agree with Daniel.  I think it's going to be difficult to get the
symtab maintainers to agree to this change.

I'm curious about why it was needed in the first place though.
SOFUN_ADDRESS_MAYBE_MISSING is alread defined for Linux.  Is it
needed for some other (non-Linux) platform?

Hmm...  it just occurred to me that SOFUN_ADDRESS_MAYBE_MISSING needs
to be multiarched.  Once that's done, your problem is solved since
this could be turned on or off at will.

Kevin

Re: Patching gdb 5.0 for XFree86 module support

[Mike A. Harris]

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

Re: Patching gdb 5.0 for XFree86 module support

[Mike A. Harris]

On Tue, 25 Sep 2001, Kevin Buettner wrote:

>> > --- gdb/dbxread.c.xfree86-modules	Sat Jul  7 13:19:50 2001
>> > +++ gdb/dbxread.c	Sun Sep 23 07:53:12 2001
>> > @@ -2272,7 +2272,7 @@
>> >  	    case 'F':
>> >  	      function_stab_type = type;
>> >  
>> > -#ifdef SOFUN_ADDRESS_MAYBE_MISSING
>> > +#if defined(SOFUN_ADDRESS_MAYBE_MISSING) || defined(XFREE_MODULE_SUPPORT)
>> >  	      /* Deal with the SunPRO 3.0 compiler which omits the address
>> >  	         from N_FUN symbols.  */
>> >  	      if (type == N_FUN
>> 
>> I'm not sure that's going to fly.  SOFUN_ADDRESS_MAYBE_MISSING
>> introduces its own problems; there's a good discussion in the list
>> archives but I can't find it at the moment.  Of course, I can see why
>> you'd need that segment.

My apologies for not answering right away, email mixup...

>I agree with Daniel.  I think it's going to be difficult to get the
>symtab maintainers to agree to this change.

Thats ok, I'll explain below.

>I'm curious about why it was needed in the first place though.
>SOFUN_ADDRESS_MAYBE_MISSING is alread defined for Linux.  Is it
>needed for some other (non-Linux) platform?

XFree86 runs on many platforms.  I am only concerned with being
able to debug XFree86 in Linux on our supported architectures 
personally though.  But if it needs that, and it only works on 
Linux, then those using other OS's wont be able to benefit.


>Hmm...  it just occurred to me that SOFUN_ADDRESS_MAYBE_MISSING needs
>to be multiarched.  Once that's done, your problem is solved since
>this could be turned on or off at will.

Sounds good to me.  Do you have any suggestion for how that 
should be done properly?

Ok, here is my explanation from above...

I've got two different goals in mind:

1) Having a build of gdb that can debug a modular XFree86 - even 
   if the code is crap and written in a bad way.  Just as long as 
   it works I am happy, even if it only works on x86.  I'll call 
   this my "I can use it now to get more work done quicker" 
   build.  ie: short term hack solution

2) If possible, having the functionality added to official gdb to
   do this in a technically 'proper' way that is clean and 
   likely not even XFree86 specific.  Again, primarily working on 
   Linux x86 minimum, but even better if it works on 
   axp/ia64/sparc, etc..  Being in mainstream gdb would allow 
   more joe blow's to debug X that wouldn't ordinarily bother to 
   jump through the hoops necessary now due to XFree86's oddball 
   nature.  This is more of a longterm solution.

If #2 is not difficult and could be done fairly easily by 
someone, or if someone could guide me as to how to go about it 
(keeping in mind I really know ziltch about gdb internals), that 
would be great.  I don't know the compexity involved so I can't 
guage how much I would be getting in over my head on this.

If #2 doesn't stand much chance of happening in the short term, 
if someone could help me hack some nasty 'code you never want 
your Mom to see' up (like the junk I posted already <grin>), or 
offer any advice on how I could conk what I have with a 12 pound 
sledge to get it to work for the interim, that would be a really 
big help to me.

Thanks for the advice guys!
Take care,
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
General open IRC discussion:    #xfree86 on irc.openprojects.org
----------------------------------------------------------------------
root@dod.usarmy.gov:~#  rm -f /bin/laden

Re: Patching gdb 5.0 for XFree86 module support

[Mike A. Harris]

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

Re: Patching gdb 5.0 for XFree86 module support

[Mike A. Harris]

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.

Just to clarify, what do you mean by 'current GDB'?  Do you mean 
current CVS of gdb, or current Rawhide GDB?  My testing is with 
Rawhide GDB since I'm wanting to use the gdb supplied with the 
distro.

>Looking at this patch and especially the comment:
>
[SNIP]
>>> + * 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.

Ok, sounds good.

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

Ok, I have actually got it running now.  I'm attaching the latest 
patch, which is partially functional anyway.

The full src.rpm of gdb with loadable XFree86 module support is 
at:  ftp://people.redhat.com/mharris/hacks/gdb-5.0rh-15.6xfree.src.rpm

I can load symbols from .o modules manually, but aparently not 
from .a's.

Ultimately, what I would like is for gdb to load the modules for 
the whole shebang all at once.  Possible?  Am I totally insane?

1Gb of RAM should suffice no?  ;o)

TIA


----------------------------------------------------------------------
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 muller@cerbere.u-strasbg.fr Mon Sep 24 03:53:00 2001
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: gdb-patches@sources.redhat.com
Cc: Christopher Faylor <cgf@redhat.com>
Subject: [RFA] Handle win32 debugger file handles
Date: Mon, 24 Sep 2001 03:53:00 -0000
Message-id: <4.2.0.58.20010924121227.01ecb100@ics.u-strasbg.fr>
X-SW-Source: 2001-09/msg00313.html
Content-length: 6914

   The following patch fixed a long stand problem with the win32 version of
GDB when used as part of an editor.
   This is the case for the FP IDE (a Free Pascal IDE
that integrates GDB for internal debugging).
See http://sources.redhat.com/ml/cygwin/2001-08/msg00147.html

   That patch is still incomplete, in the sense that
this does allow to change the executable after
running it under the debugger, but we still leave
open file handles for all used dlls.
   The problem here is that the corresponding struct object
are not freed when the program is exited or killed. As I am unsure how
to solve this secondary problem (less people use the IDE to debug DLLs)
I send this patch with that problem pending.


2001-09-22  Pierre Muller  <muller@ics.u-strasbg.fr>

	* win32-nat.c: Handle hFile fields given by WaitForDebugEvent
              when dwDebugEventCode is either CREATE_PROCESS_DEBUG_EVENT
              or LOAD_DLL_DEBUG_EVENT.
              (current_process_file_handle): New static variable.
              (struct so_stuff): Add new field hFile.
              (register_loaded_dll): Add new arg: hFile.
              (handle_load_dll): Adapt to new register_loaded_dll function.
              (handle_unload_dll): New function.
              (child_clear_solibs):  Close hFile handles if valid.
              (child_clear_solib_handles): New function that closes all 
open handles.
              (get_child_debug_event): set or close the different file handles.
	   (core_dll_symbols_add): adapt to modified register_loaded_dll function.

Index: win32-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.27
diff -u -r1.27 win32-nat.c
--- win32-nat.c	2001/05/04 04:15:28	1.27
+++ win32-nat.c	2001/09/24 10:21:50
@@ -105,6 +105,7 @@
  static DEBUG_EVENT current_event;	/* The current debug event from
  					   WaitForDebugEvent */
  static HANDLE current_process_handle;	/* Currently executing process */
+static HANDLE current_process_file_handle;	/* Currently executing process 
file handle */
  static thread_info *current_thread;	/* Info on currently selected thread */
  static DWORD main_thread_id;	/* Thread ID of the main thread */

@@ -493,6 +494,7 @@
  {
    struct so_stuff *next, **last;
    DWORD load_addr;
+  HANDLE hFile;
    char name[0];
  }
  solib_start, *solib_end;
@@ -501,12 +503,17 @@
  int max_dll_name_len;

  static void
-register_loaded_dll (const char *name, DWORD load_addr)
+register_loaded_dll (const char *name, DWORD load_addr, HANDLE hFile)
  {
+  int len;
    struct so_stuff *so;
    so = (struct so_stuff *) xmalloc (sizeof (struct so_stuff) + strlen 
(name) + 8 + 2);
    so->load_addr = load_addr;
+  so->hFile = hFile;
    strcpy (so->name, name);
+  len = strlen (name);
+  if (len > max_dll_name_len)
+    max_dll_name_len = len;

    solib_end->next = so;
    solib_end = so;
@@ -597,14 +604,35 @@
    while ((p = strchr (dll_name, '\\')))
      *p = '/';

-  register_loaded_dll (dll_name, (DWORD) event->lpBaseOfDll + 0x1000);
-  len = strlen (dll_name);
-  if (len > max_dll_name_len)
-    max_dll_name_len = len;
+  register_loaded_dll (dll_name, (DWORD) event->lpBaseOfDll + 0x1000, 
event->hFile);

    return 1;
  }

+static int
+handle_unload_dll (void * lpBaseOfDll)
+{
+  struct so_stuff *so = &solib_start, *so1 = solib_start.next;
+
+  while (so1 != NULL)
+    {
+      if (so1->load_addr == ((DWORD) lpBaseOfDll) + 0x1000)
+        {
+
+          if (so1->hFile != INVALID_HANDLE_VALUE)
+            CloseHandle(so1->hFile);
+          /* FIXME: There is still no function to unload
+             the symbols loaded by this DLL */
+          so->next = so1->next;
+          xfree(so1);
+          return 1;
+        }
+      so = so1;
+      so1 = so->next;
+    }
+ return 0;
+}
+
  /* Return name of last loaded DLL. */
  char *
  child_solib_loaded_library_pathname (int pid ATTRIBUTE_UNUSED)
@@ -620,6 +648,8 @@

    while ((so = so1) != NULL)
      {
+      if (so1->hFile != INVALID_HANDLE_VALUE)
+        CloseHandle(so1->hFile);
        so1 = so->next;
        xfree (so);
      }
@@ -629,6 +659,21 @@
    max_dll_name_len = sizeof ("DLL Name") - 1;
  }

+/* Close handles of list of loaded DLLs. */
+void
+child_clear_solib_handles (void)
+{
+  struct so_stuff *so = solib_start.next;
+
+  while (so != NULL)
+    {
+      if (so->hFile != INVALID_HANDLE_VALUE)
+        CloseHandle(so->hFile);
+      so->hFile = INVALID_HANDLE_VALUE;
+      so = so->next;
+    }
+}
+
  /* Add DLL symbol information. */
  void
  solib_symbols_add (char *name, CORE_ADDR load_addr)
@@ -869,6 +914,7 @@
  		     (unsigned) current_event.dwThreadId,
  		     "CREATE_PROCESS_DEBUG_EVENT"));
        current_process_handle = current_event.u.CreateProcessInfo.hProcess;
+      current_process_file_handle = current_event.u.CreateProcessInfo.hFile;

        main_thread_id = current_event.dwThreadId;
        /* Add the main thread */
@@ -889,6 +935,8 @@
        ourstatus->kind = TARGET_WAITKIND_EXITED;
        ourstatus->value.integer = current_event.u.ExitProcess.dwExitCode;
        CloseHandle (current_process_handle);
+      CloseHandle (current_process_file_handle);
+      child_clear_solib_handles ();
        retval = main_thread_id;
        break;

@@ -897,7 +945,7 @@
  		     (unsigned) current_event.dwProcessId,
  		     (unsigned) current_event.dwThreadId,
  		     "LOAD_DLL_DEBUG_EVENT"));
-      catch_errors (handle_load_dll, NULL, (char *) "", RETURN_MASK_ALL);
+      catch_errors (handle_load_dll, NULL, (char *) "Error in 
handle_load_dll", RETURN_MASK_ALL);
        registers_changed ();	/* mark all regs invalid */
        ourstatus->kind = TARGET_WAITKIND_LOADED;
        ourstatus->value.integer = 0;
@@ -909,6 +957,7 @@
  		     (unsigned) current_event.dwProcessId,
  		     (unsigned) current_event.dwThreadId,
  		     "UNLOAD_DLL_DEBUG_EVENT"));
+      catch_errors (handle_unload_dll, (void *) 
current_event.u.UnloadDll.lpBaseOfDll, (char *) "Error in 
handle_unload_dll", RETURN_MASK_ALL);
        break;			/* FIXME: don't know what to do here */

      case EXCEPTION_DEBUG_EVENT:
@@ -1272,6 +1321,9 @@
      }

    CHECK (CloseHandle (current_process_handle));
+  /* Close all file handles given by the OS */
+  CHECK (CloseHandle (current_process_file_handle));
+  child_clear_solib_handles ();

    /* this may fail in an attached process so don't check. */
    (void) CloseHandle (current_thread->h);
@@ -1489,7 +1541,7 @@
        }
    }

-  register_loaded_dll (dll_name, base_addr + 0x1000);
+  register_loaded_dll (dll_name, base_addr + 0x1000, INVALID_HANDLE_VALUE);
    solib_symbols_add (dll_name, (CORE_ADDR) base_addr + 0x1000);

  out:




Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99