From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3668 invoked by alias); 3 May 2007 20:08:52 -0000 Received: (qmail 3659 invoked by uid 22791); 3 May 2007 20:08:51 -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; Thu, 03 May 2007 20:08:49 +0000 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id C652F4B267; Thu, 3 May 2007 15:08:45 -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 AEE834B262; Thu, 3 May 2007 15:08:45 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1HjhbY-0000G6-Ly; Thu, 03 May 2007 16:08:44 -0400 Date: Thu, 03 May 2007 20:08:00 -0000 From: Daniel Jacobowitz To: Pedro Alves Cc: gdb@sourceware.org Subject: Re: Win32 gdbserver dll support. Message-ID: <20070503200844.GA727@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> <20070430024531.GA3880@caradoc.them.org> <20070503153703.GA20130@caradoc.them.org> <4053daab0705030911v4be55c85jcce7d0fb2d24dde0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4053daab0705030911v4be55c85jcce7d0fb2d24dde0@mail.gmail.com> 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-05/txt/msg00008.txt.bz2 On Thu, May 03, 2007 at 05:11:42PM +0100, Pedro Alves wrote: > Glad you're working on this, and was going to report tonight :) > > I looked into it last night too. I've got cygwin native working with > your solib-target.c, to get a feeling if it would be a good match. It is. > There is just one case, that I bet you'll be looking into, which is > the relocate_section_addresses solib-target op. Your implementation > was elf specific. To get it up working as a fast prototype, I used > a method that wouldn't work for elf. Yep. I've been moving the ELF-specific bits into elfread.c for the last hour. For Windows this should be easy, since it looks like DLLs are always relocated by a single offset; does Windows CE relocate text and data by different amounts, or is there still a single image base? > I stumbled on core dump support, dll loading. Current win32-nat.c > reads the dlls > that were loaded in the core, on win32_current_sos, depending on core_bfd > being set. Perhaps we need a new op somewhere, maybe in struct core_fns too. You're probably right; then corelow can implement the to_get_shared_libraries method. > Perhaps you would want to take a look at my changes, to get a better feeling > of what is needed for win32. I'll get home in a few hours. Yes please. I'll try to combine all the pieces. -- Daniel Jacobowitz CodeSourcery