From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14376 invoked by alias); 9 May 2007 20:40:30 -0000 Received: (qmail 14366 invoked by uid 22791); 9 May 2007 20:40:29 -0000 X-Spam-Check-By: sourceware.org Received: from az18ip152.honeywell.com (HELO az18ip152.honeywell.com) (199.64.7.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 May 2007 20:40:27 +0000 Received: from unknown (HELO AZ18CN851.global.ds.honeywell.com) ([131.127.167.139]) by az18ip152.honeywell.com with ESMTP; 09 May 2007 13:40:05 -0700 X-IronPort-AV: i="4.14,511,1170658800"; d="scan'208"; a="103741101:sNHT825728274" Received: from AZ18EV808.global.ds.honeywell.com ([131.127.167.102]) by AZ18CN851.global.ds.honeywell.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 13:40:05 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [rfc / remote protocol] Remote shared library events Date: Wed, 09 May 2007 20:40:00 -0000 Message-ID: In-Reply-To: <20070509201627.GA23422@caradoc.them.org> References: <20070509201627.GA23422@caradoc.them.org> From: "Smith, Stephen \(SWCOE\)" To: X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-05/txt/msg00039.txt.bz2 I used an earlier version of Daniel's patch to implement do something similar on the os that I am working on. So I am interested in seeing this go through. sps -----Original Message----- From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf Of Daniel Jacobowitz Sent: Wednesday, May 09, 2007 1:16 PM To: gdb-patches@sourceware.org Cc: gdb@sourceware.org Subject: [rfc / remote protocol] Remote shared library events System V platforms (like GNU/Linux, Solaris, BSD, et cetera) have a mostly userspace shared library loader. That means the loader already has to keep track of what libraries are mapped, and GDB uses the same data structures that the loader does to find the list. There's also typically an application function like _dl_debug_state which is called at every event; GDB can set a breakpoint there to be notified of events. Not all platforms work this way. The exceptions I'm looking at recently are DLL-based platforms: Windows and SymbianOS. Both use an OS-level loader instead. You have to query the OS to get the list of libraries, and the OS provides event notification directly instead of via a magic breakpoint. We can't poke and prod at the OS directly during remote debugging, so to implement DLL support for these platforms I extended the remote protocol. The additions are three new stop replies for the "T" packet to report events (load, unload, and dll for "something more complicated than just a load or unload") and two new packets (qfDllInfo and qsDllInfo) to query the current state. Detailed documentation is below and the patch is attached. This patch introduces a new solib_ops vector in solib-target.c. This vector is target driven; it maintains a list based on the query packet and event notices, instead of looking through memory. I have tested this code on SymbianOS, Cygwin, and MinGW32. Pedro Alves has tested a slightly earlier version on Windows CE (and wrote the gdbserver bits I used to test it on Windows - thanks!). What do you think, Kevin especially? I'm not entirely thrilled with the way this interacts with other solib_ops vectors, but I'm not unhappy with it either. Eli, do the manual changes look OK? All comments welcome!