From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23581 invoked by alias); 10 May 2007 21:35:08 -0000 Received: (qmail 23569 invoked by uid 22791); 10 May 2007 21:35:07 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 May 2007 21:35:03 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.0/8.14.0) with ESMTP id l4ALYpNK032345; Thu, 10 May 2007 23:34:51 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.0/8.14.0/Submit) id l4ALYpQU016401; Thu, 10 May 2007 23:34:51 +0200 (CEST) Date: Thu, 10 May 2007 21:35:00 -0000 Message-Id: <200705102134.l4ALYpQU016401@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sourceware.org In-reply-to: <20070509201627.GA23422@caradoc.them.org> (message from Daniel Jacobowitz on Wed, 9 May 2007 16:16:27 -0400) Subject: Re: [rfc / remote protocol] Remote shared library events References: <20070509201627.GA23422@caradoc.them.org> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-05/txt/msg00168.txt.bz2 > Date: Wed, 9 May 2007 16:16:27 -0400 > From: Daniel Jacobowitz > > 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. Can we please avoid the term DLL for this stuff? That's just a particular implementation of shared objects/libraries. This functionality is generally usable, and not specific to Windows. > 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. I think this diff needs to be split up. I looked at it twice now, but I don't see how the bits are related, and the changes to infrun.c make me very nervous. Mark