From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29980 invoked by alias); 26 Apr 2007 22:27:26 -0000 Received: (qmail 29967 invoked by uid 22791); 26 Apr 2007 22:27:25 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.173) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Apr 2007 23:27:22 +0100 Received: by ug-out-1314.google.com with SMTP id 75so609653ugb for ; Thu, 26 Apr 2007 15:27:20 -0700 (PDT) Received: by 10.66.236.13 with SMTP id j13mr1964518ugh.1177626440391; Thu, 26 Apr 2007 15:27:20 -0700 (PDT) Received: from ?88.210.68.18? ( [88.210.68.18]) by mx.google.com with ESMTP id 54sm69220ugp.2007.04.26.15.27.17; Thu, 26 Apr 2007 15:27:19 -0700 (PDT) Message-ID: <4631274C.5080603@portugalmail.pt> Date: Thu, 26 Apr 2007 22:27:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Pedro Alves CC: gdb@sourceware.org Subject: Re: Win32 gdbserver dll support. References: <4053daab0704260940t4e0a9593lc706794c718cc3a9@mail.gmail.com> In-Reply-To: <4053daab0704260940t4e0a9593lc706794c718cc3a9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00157.txt.bz2 Pedro Alves escreveu: > Hi guys, > > I'm looking into adding dll support to gdbserver, primarily > for WinCE, but Cygwin would also benefit, of course. > > I realize that solib support for svr4 targets works without > special remote protocol support, because you can get at the > link maps by just fiddling with the inferior memory, and > putting breakpoints in the special places on the loader. > > There are some targets, where that isn't possible, like > Windows, where the dynamic loader is part of the OS, or > targets where the link map must the read from the /proc > file system. > > Current native Windows support (win32-nat.c), autoloads > the dlls symbols immediately when a LOAD_DLL_DEBUG event > arrives, bypassing a bit the normal solib.c interface. > I have a patch for that, that makes win32 fetch the > loaded dlls every time through current_sos, and making > win32_relocate_section_address to its job. > > It looks like that what is needed is a way to > somehow ask gdbserver for a virtual link map, perhaps in > textual form, that could be parsed by gdb much like one > parses the map on /proc/ targets. That would also fit > nicely for those targets, except they would return a > copy of the real link map file, whereas Win32 would return > a file generated on the fly. Eg. If AIX got gdbserver > support, it could call > target_ops->fetch_inferior_file ("/proc//map") in > build_so_list_from_mapfile, and do the same parsing as it > already does. The fetch_inferior_file > target_op could have a default implementation of reading > a local file so native debugging would work unaffected. > > Another alternative, would be to add > TARGET_WAITKIND_LOADED state to the remote protocol > (an 'L' packet perhaps), and somehow > marshall the lm_info data with the state change notification, > which is specific for each different target_so_ops. > I don't like this much, since there are targets where > you would find yourself in marshalling pointers, meaning > that probably it would be more invasive, then needs be. > It may be more efficient, since we wouldn't fetch the whole > solibs list everytime, but build it on the gdb size. On the > other hand, fetching the map in one go probably isn't > that inefficient. > > Adding full support for remote opening, > seeking, stating, etc, is certainly doable, but perhaps > a bit out of scope for simplicity of the remote protocol? > I actually bit the bullet and I'm investigating/implementing remote open/close/read/write/lseek. It seems to be enough for now. If there are any objections, please speak up, you'll probably save me "a couple" of hours ;) > Adding a simple 'char* read_remote_file (const char* filename)' > in target_ops, that reads the whole file at once would > suffice for the problem at hands. I'm ignoring buffering > problems on purpose, since map files tend to be small. > I would have to add TARGET_WAITKIND_LOADED state to > the remote protocol for dll loading/unloadind notification, > but without passing any data to gdb, > and then gdb would fetch the dlls list with > current_sos + fetch_remote_file in reaction to the > state change. infrun.c:handle_inferior_event already does that, > but it is guarded on '#ifdef SOLIB_ADD'. It would be a matter > of exposing it always. > > Any ideas? Perhaps something simpler I'm not seing? > > Daniel, I once saw somewhere on the archives that > you have once made win32 dlls work with gdbserver. I can't > find that pointer now, though. Do you have at hand that > implementation, or remember the interface you used/implemented? > > Cheers, > Pedro Alves >