Re: A revised patch for dlclose

[Jim Kingdon <kingdon at redhat dot com>]

> HJ, please stop wasting your time pushing this patch.  The patch has
> several bad points

Agreed.

> that you cannot fix without considerable changes to the way solib.c
> handles and caches the link map.

Could you elaborate, Mark?  

For example, I've been thinking of splitting find_solib into two
functions.  One (to be called find_solib) which just traverses the
linked list in GDB and the other (to be called solib_recheck) which
looks at the inferior and updates GDB's linked list.

This is inspired at least in part by certain elements of the FreeBSD solib.c:
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/gdb/gdb/solib.c?rev=1.7
although on the whole the FreeBSD code looked buggy/undesirable
(unless I misread it, which is of course possible).

I do agree with HJ about one thing, though, which is that this issue
is rather important.  I'm trying to put my money where my mouth is by
writing code but I'll have to admit that JimB's message left me a
little unsure about where to turn.

I don't know if I'd be upset if we have a great patch which is clean
and works and which has to wait until after GDB 5.0 because it is too
big a change.  But I would be disappointed if the issue just dies and
GDB users once again have to choose between getting their work done
and GDB code which is maintainable/maintained/clean/&c.

Now, I can try to con JimB into taking my patch.  For example a
comment in find_solib along the lines of "If !recheck, skip almost all
the reads from the inferior, and just return information from our own
data structures" might make the logic slightly less obscure and JimB
is right about the memory leak at the "build a local abbreviated
load_map structure", and I'd be glad to fix that.  But at least for
the moment I had in mind trying out the find_solib/solib_recheck idea
and see if writing that code seems to get us anywhere (not that I got
around to actually doing it despite spending hours thinking about it
today, mind you).