This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: [hercules@lokigames.com: GDB shared library problems (test case)]
"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