From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13805 invoked by alias); 2 Oct 2003 05:43:29 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13785 invoked from network); 2 Oct 2003 05:43:19 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 2 Oct 2003 05:43:19 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h925hJ100396 for ; Thu, 2 Oct 2003 01:43:19 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h925hJc08396; Thu, 2 Oct 2003 01:43:19 -0400 Received: from localhost.localdomain (vpn50-46.rdu.redhat.com [172.16.50.46]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h925hIbe008720; Thu, 2 Oct 2003 01:43:18 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h925hDI15016; Wed, 1 Oct 2003 22:43:13 -0700 Date: Thu, 02 Oct 2003 05:43:00 -0000 From: Kevin Buettner Message-Id: <1031002054312.ZM15015@localhost.localdomain> In-Reply-To: Stephen & Linda Smith "Shared libraries and the solib interface" (Oct 1, 9:11pm) References: <3F7BA58F.9050803@cox.net> To: Stephen & Linda Smith , gdb Subject: Re: Shared libraries and the solib interface MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00049.txt.bz2 On Oct 1, 9:11pm, Stephen Smith wrote: > I am thinking of working on using writing a solib-remote.c interface > file to implement loading of shared libraries. I believe that this is > what Kevin suggested a couple of years ago, but I was too stuborn and > dropped it. The item that I am confused about is how to have the remote > box (which uses the current remote protocol) communicate back to the > host the fact that a shared library has been loaded. Does anyone have > suggestions? One common way of doing this is to have gdb place a breakpoint in some function which is called when there's a change in the set of shared libraries that the target has loaded. This is usually just a stub that the dynamic linker provides explicitly for this purpose. Then, when that breakpoint has been hit, gdb can query the target for a list of loaded shared libraries. If the stub can tell gdb specifically which libraries have just been loaded, so much the better. As I recall, the loading is not distinguished from unloading, so gdb usually (always?) just fetches the entire list of currently loaded shared libraries from the target. This approach can be used even if the dynamic linker doesn't provide a convenient function (or even an inconvenient function) to set a breakpoint on. In such a case, the stub is presumably informed via other means of the fact that a shared library has just been loaded. The stub could stop and tell GDB that it's just hit a fake "shared library loaded" breakpoint. Your solib backend (on the GDB side) and the stub would have to agree on some suitable address to use for this purpose. There is some risk associated with lying to GDB in such a manner, but this risk is mitigated by the fact that users don't usually stop at these internal breakpoints. [Setting ``stop-on-solib-events'' does allow the user to stop though. Once you get the basic machinery going, you'll want to remember to test with this setting to make sure it's not too badly broken. It can, at times, be extremely useful to allow a user-level stop when a solib related breakpoint has been hit.] There are other approaches that could be used, but most of these would involve adding code to other (generic) portions of gdb. Since it's more difficult to get approval for changes to generic code, it's probably best to stick with mechanisms which are already in use by other targets. HTH, Kevin