From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22047 invoked by alias); 3 May 2007 16:11:51 -0000 Received: (qmail 22038 invoked by uid 22791); 3 May 2007 16:11:50 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.175) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 May 2007 16:11:45 +0000 Received: by ug-out-1314.google.com with SMTP id 75so413341ugb for ; Thu, 03 May 2007 09:11:42 -0700 (PDT) Received: by 10.78.180.18 with SMTP id c18mr984852huf.1178208702318; Thu, 03 May 2007 09:11:42 -0700 (PDT) Received: by 10.78.66.14 with HTTP; Thu, 3 May 2007 09:11:42 -0700 (PDT) Message-ID: <4053daab0705030911v4be55c85jcce7d0fb2d24dde0@mail.gmail.com> Date: Thu, 03 May 2007 16:11:00 -0000 From: "Pedro Alves" To: gdb@sourceware.org Subject: Re: Win32 gdbserver dll support. In-Reply-To: <20070503153703.GA20130@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> X-Google-Sender-Auth: 185e2f6f3573f7d6 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/msg00006.txt.bz2 Hi Daniel, On 5/3/07, Daniel Jacobowitz wrote: > On Sun, Apr 29, 2007 at 10:45:31PM -0400, Daniel Jacobowitz wrote: > > > I'll take a deeper look at the patch in a couple of days. > > > > Thanks. So will I. Maybe I can simplify it further. > > FYI, I'm still working on this. I've got all of my existing code to > work with trunk at last. > 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. 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. Anyway, I'm writing this on a hurry. 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. Cheers, Pedro Alves