From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15876 invoked by alias); 4 Jan 2007 20:37:48 -0000 Received: (qmail 15853 invoked by uid 22791); 4 Jan 2007 20:37:47 -0000 X-Spam-Check-By: sourceware.org Received: from tmpnat1.honeywell.com (HELO AZ18CN851.global.ds.honeywell.com) (199.64.0.252) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 04 Jan 2007 20:37:42 +0000 Received: from AZ18EV808.global.ds.honeywell.com ([131.127.167.102]) by AZ18CN851.global.ds.honeywell.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 13:37:40 -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: GDB solib interface Date: Thu, 04 Jan 2007 20:37:00 -0000 Message-ID: In-Reply-To: <20061208211922.GA28061@nevyn.them.org> From: "Smith, Stephen \(SWCOE\)" To: "Daniel Jacobowitz" , "General GDB Mailing List" 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-01/txt/msg00064.txt.bz2 You say below that if you dll:dll is returned, GDB should query the target for the state of the dlls. Does this mean that GDB would "forget" the dll information that it received previously and then reissue the qfDllInfo/qsDllInfo queries? The text you wrote: Reporting DLL events -------------------- The `T' stop packet response is extended to take three additional N:R pairs. When any of these are encountered, the stopped thread is assumed to be at a DLL event. The signal should be SIGTRAP. There may be multiple load and unload events in the stop packet. `load:Name=3DHEXSTR,TextSeg=3DADDR,DataSeg=3DADDR[,nop]' A new DLL has been loaded; it is described in the stop packet. If "nop" is specified, this DLL was already loaded, e.g. by an earlier call to dlopen. `unload:IDENTIFIER=3DVALUE[,nop]' A DLL has been unloaded. A single identifier is provided to uniquely identify which DLL has been unloaded. Depending on the target, this may be the text or data address; the name can be used, but may not be unambiguous. If "nop" is specified, this DLL was not unloaded, e.g. because another thread still had a handle to it. `dll:dll' Multiple DLL events have occured. GDB should query the target for the current state of DLLs.