From: Daniel Jacobowitz <drow@false.org>
To: gdb@sourceware.org
Subject: Re: How does solib handline shared library unloads?
Date: Tue, 01 Nov 2005 13:51:00 -0000 [thread overview]
Message-ID: <20051101135142.GA25595@nevyn.them.org> (raw)
In-Reply-To: <20051101134547.GA3098@trixie.casa.cgf.cx>
On Tue, Nov 01, 2005 at 08:45:47AM -0500, Christopher Faylor wrote:
> On Tue, Nov 01, 2005 at 07:58:35AM +0100, Mark Kettenis wrote:
> >> Date: Tue, 1 Nov 2005 00:39:34 -0500
> >> From: Christopher Faylor
> >>
> >> Can anyone enlighten me as to how information about a library is
> >> relinquished when a library loaded via dlopen is unloaded via dlclose?
> >> Theoretically, the information about the library should be removed and
> >> the library should not be listed by "info sharedlibrary".
> >>
> >> I don't see any way for this to be handled in solib.c and inf*.c but I'm
> >> sure I'm just missing something obvious. I haven't written a test case
> >> yet to see how it is being handled but I was hoping someone could
> >> clarify this for me.
> >
> >It happens as part of solib_add(), which should be called for every
> >shared library events, not just dlopen()s. See the code in
> >update_solib_list() for the code that actually removes libraries from
> >GDB's internal list.
>
> Is this handled as part of the so breakpoint stuff? I was trying to
> avoid implementing that but I will if I have to.
Well, that's how we get to solib_add for svr4 targets; but it should
work to get there off an explicit DLL unload event, anyway. I think.
> >That said, I think I have convinced myself in the past that there is a
> >big gaping memory leak.
>
> I was wondering about that. I thought there might be a big memory leak
> there since it doesn't look like objfile's are being freed.
I'm not sure... ideally, I'd rather they were neither freed nor leaked,
since we're likely to load them again. But that may be a lot of work
yet.
--
Daniel Jacobowitz
CodeSourcery, LLC
next prev parent reply other threads:[~2005-11-01 13:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-01 5:39 Christopher Faylor
2005-11-01 6:59 ` Mark Kettenis
2005-11-01 13:45 ` Christopher Faylor
2005-11-01 13:51 ` Daniel Jacobowitz [this message]
2005-11-01 14:40 ` Christopher Faylor
2005-11-01 15:12 ` Daniel Jacobowitz
2005-11-01 16:20 ` Christopher Faylor
2005-11-01 16:24 ` Daniel Jacobowitz
2005-11-01 18:24 ` Mark Kettenis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051101135142.GA25595@nevyn.them.org \
--to=drow@false.org \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox