From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14580 invoked by alias); 30 Apr 2007 02:45:37 -0000 Received: (qmail 14570 invoked by uid 22791); 30 Apr 2007 02:45:37 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Apr 2007 03:45:34 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id 62EBF4B26F; Sun, 29 Apr 2007 21:45:32 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id 23D5E4B26D; Sun, 29 Apr 2007 21:45:31 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1HiLtL-0001Ay-5t; Sun, 29 Apr 2007 22:45:31 -0400 Date: Mon, 30 Apr 2007 02:45:00 -0000 From: Daniel Jacobowitz To: Pedro Alves Cc: gdb@sourceware.org Subject: Re: Win32 gdbserver dll support. Message-ID: <20070430024531.GA3880@caradoc.them.org> Mail-Followup-To: Pedro Alves , gdb@sourceware.org References: <4053daab0704260940t4e0a9593lc706794c718cc3a9@mail.gmail.com> <4631274C.5080603@portugalmail.pt> <20070426224438.GA14312@caradoc.them.org> <463136E8.8060700@portugalmail.pt> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <463136E8.8060700@portugalmail.pt> User-Agent: Mutt/1.5.15 (2007-04-09) 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-04/txt/msg00162.txt.bz2 On Fri, Apr 27, 2007 at 12:34:00AM +0100, Pedro Alves wrote: > I was trying to avoid doing what you've done with > solib-target.c the same solib-*.c when native or remote debugging. > That is, keeping the remote/native vs 'solib target' separate. That's the bit I liked least too. I don't remember exactly how it worked, but my intention was to use the same solib module for local or remote debugging; we could switch Windows to reuse solib-target.c (if it was simpler that way). The problem is that there are two solib models. One, SysV's, does not require any target specific operations. That's a property of the architecture. The other, which Windows et al use, is (sort of) independent of the architecture, but requires information from the target. The best I could think of was this, which lets the architecture defer to the target. > Are you sure that textSeg+dataSeg is enough? That is the lm_info > marshaling stuff I was talking about. By reading a remote file, > you let the solib-*.c implementation handle that. Ok, you can > pass name/value pairs, but then you have to add support for > the new pairs on solib-target.c ? Text and data segment addresses were enough for me. I think they would suffice for Windows, too. But I'm not sure; the way it worked on SymbianOS was that GDB ended up loading ELF files rather than the target-format DLLs, and loading DLLs might impose some different requirements. If it's not enough, maybe we could use the architecture methods to specialize solib-target.c without cluttering it; it could be taught to keep track of arbitrary name/value pairs without knowing what they were. Or maybe there's a better design entirely. I decided to add the load and unload events, even though they complicated things a bit, because they're the most common case. On GNU/Linux the number of loaded libraries is usually relatively small. On SymbianOS, it's not small - in fact it's mammoth. There's usually about fifty DLLs, and I was using a serial connection to the target. So, slow's the word. > I'll take a deeper look at the patch in a couple of days. Thanks. So will I. Maybe I can simplify it further. -- Daniel Jacobowitz CodeSourcery