From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19116 invoked by alias); 26 Apr 2007 16:41:02 -0000 Received: (qmail 19107 invoked by uid 22791); 26 Apr 2007 16:41:01 -0000 X-Spam-Check-By: sourceware.org Received: from ik-out-1112.google.com (HELO ik-out-1112.google.com) (66.249.90.176) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Apr 2007 17:40:56 +0100 Received: by ik-out-1112.google.com with SMTP id b32so267875ika for ; Thu, 26 Apr 2007 09:40:53 -0700 (PDT) Received: by 10.78.158.11 with SMTP id g11mr564005hue.1177605653108; Thu, 26 Apr 2007 09:40:53 -0700 (PDT) Received: by 10.78.66.14 with HTTP; Thu, 26 Apr 2007 09:40:53 -0700 (PDT) Message-ID: <4053daab0704260940t4e0a9593lc706794c718cc3a9@mail.gmail.com> Date: Thu, 26 Apr 2007 16:41:00 -0000 From: "Pedro Alves" To: gdb@sourceware.org Subject: Win32 gdbserver dll support. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 412b4954c59afb65 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/msg00156.txt.bz2 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? 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