Re: [hercules@lokigames.com: GDB shared library problems (test case)]

[Andrew Cagney <ac131313 at cygnus dot com>]

"H . J . Lu" wrote:
> 
> On Fri, Feb 04, 2000 at 09:58:24PM +0100, Mark Kettenis wrote:
> >    Date: Fri, 4 Feb 2000 12:40:09 -0800
> >    From: "H . J . Lu" <hjl@lucon.org>
> >
> > HJ,
> >
> > Looks like Sam sent you a test case.  Could you post that here too?
> > I'm not convinced that adding yet another hook to infrun.c is the
> > right solution, so I'd like to take a closer look if Jim doesn't mind.
> > It might be useful to have a rgeression test for this problem too.
> >
> 
> Here it is. BTW, I forwarded another patch from Sam:
> 
> Wed Mar 17 19:49:22 1999  Sam Lantinga (slouken@devolution.com)
> 
>         Added function check_solib_consistency() to reload list of
>         shared objects when they are added or deleted. This fixed
>         crashing when the program being debugged unloaded a dynamic
>         library and added a new library afterwards.
> 
>         * solib.h (CHECK_SOLIB_CONSISTENCY): New.
>         (check_solib_consistency): New prototype.
> 
>         * solib.c (check_solib_consistency): Defined.
> 
>         * infrun.c (handle_inferior_event): Before calling SOLIB_ADD (),
>         call CHECK_SOLIB_CONSISTENCY () if defined.
> 
> a while ago:
> 
> http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00175.html
> 
> What happened to it?

Unfortunately I don't know.

I did notice that before the maintainer starts to seriously consider
this patch a number of problems were going to need to be addressed: the
code doesn't meet FSF coding standards; the need to document the new
macro; the lack of a test case (or even output) demonstrating both the
bug and the fact that the patch fixes it; the likely need for a
copyright assignment for this new code.

My guess is that these problems caused the patch to be pushed to one
side where it eventually slipped and fell onto the floor :-(.

One thing that can be done and will help address this on going problem
is documentation (web pages / texinfo) clearly explaining the
expectations that both the maintainer and the contributor should have
when processing a patch.  At present, each time a new patch comes it,
the maintainer has to re-start that same process.  Its my intention (and
very high on my agenda) to draft documentation explaining exactly what
both parties should expect.

	sorry,
		Andrew