From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22034 invoked by alias); 2 Oct 2003 19:15:38 -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 21981 invoked from network); 2 Oct 2003 19:15:36 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 2 Oct 2003 19:15:36 -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 h92JFZ118642 for ; Thu, 2 Oct 2003 15:15:35 -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 h92JFZc23190; Thu, 2 Oct 2003 15:15:35 -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 h92JFYbe025490; Thu, 2 Oct 2003 15:15:35 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h92JFTI18320; Thu, 2 Oct 2003 12:15:29 -0700 Date: Thu, 02 Oct 2003 19:15:00 -0000 From: Kevin Buettner Message-Id: <1031002191528.ZM18319@localhost.localdomain> In-Reply-To: Stephen & Linda Smith "Re: Shared libraries and the solib interface" (Oct 1, 11:29pm) References: <3F7BA58F.9050803@cox.net> <1031002054312.ZM15015@localhost.localdomain> <3F7BC5AD.9020706@cox.net> To: Stephen & Linda Smith Subject: Re: Shared libraries and the solib interface Cc: gdb MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00061.txt.bz2 On Oct 1, 11:29pm, Stephen Smith wrote: > Kevin Buettner wrote: > > >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.] > > Do you know of an example of this? No. I thought of it last night as I was typing the first part of the explanation. If you wind up doing it this way, I'll be very interested to see how it turns out. > And a second question is how does a > generic stub inform the GDB (workstation side) app which shared library > got loaded and where or is this not necessary? For svr4- and sunos-like shared library support, this information is available by examining the target's memory. If this sort of mechanism is not available for your target, I suggest one of two approaches: 1) Add new 'q' packets for fetching the information. 2) Use the qRcmd packet for fetching it. The difference between these two approaches is subtle, because either way you'll have to devise and adhere to some sort of protocol for fetching the library information. However, with option 1 (new 'q' packet(s)), you'll have to submit a proposal for the suggested protocol changes for public inspection and commentary. It could take quite some time to finalize the protocol specification. E.g, take a look at the interaction that took place with regard to Daniel Jacobowitz's recent thread packet proposals. The qRcmd approach will likely be quicker/easier to do because the interface you devise can be private between GDB's solib backend and the stub. My suggestion is to start with qRcmd and see how the implementation turns out. With that under your belt, you may then be in a better position to suggest a specification for a set of shared library specific 'q' packets. Kevin