From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26673 invoked by alias); 8 Jul 2009 15:31:32 -0000 Received: (qmail 26662 invoked by uid 22791); 8 Jul 2009 15:31:31 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_55,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hel.is.scarlet.be (HELO hel.is.scarlet.be) (193.74.71.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Jul 2009 15:31:21 +0000 Received: from [172.17.1.10] (ip-81-11-241-231.dsl.scarlet.be [81.11.241.231]) by hel.is.scarlet.be (8.14.2/8.14.2) with ESMTP id n68FV4rN011245; Wed, 8 Jul 2009 17:31:05 +0200 Subject: Re: How to fix solib path name? From: Danny Backx Reply-To: danny.backx@scarlet.be To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: <200907081607.22830.pedro@codesourcery.com> References: <1247063678.3870.59.camel@pavilion> <200907081556.09821.pedro@codesourcery.com> <200907081607.22830.pedro@codesourcery.com> Content-Type: text/plain Date: Wed, 08 Jul 2009 15:31:00 -0000 Message-Id: <1247067073.3870.69.camel@pavilion> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-DCC-scarlet.be-Metrics: hel 20001; Body=3 Fuz1=3 Fuz2=3 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00255.txt.bz2 On Wed, 2009-07-08 at 16:07 +0100, Pedro Alves wrote: > On Wednesday 08 July 2009 15:56:09, Pedro Alves wrote: > > On Wednesday 08 July 2009 15:34:38, Danny Backx wrote: > > > I'm preparing a gdb patch so it works in a cross-debugging environment. > > > Host I'm using is a linux pc, target is running Windows CE Embedded 6.0. > > > > > > The gdbserver part is getting complete, see other messages on this list. > > > > > > The gdb still has a quirck or two. > > > > > > (gdb) info sharedlibrary > > > >From To Syms Read Shared Object Library > > > No \network\x86\libgcc_s_sjlj-1.dll > > > 0x41ee1000 0x41fb2974 > > > Yes /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++-6.dll > > > No \Windows\coredll.dll > > > (gdb) > > > > > > I'm guessing that it should strip the \network\x86 from the library name > > > before it attempts to find it in the solib-search-path. > > > > > > > Interesting. Does this mean that CE6 always reports absolute path > > names in dll events? If so, you want to use "set sysroot", not > > "set solib-search-path". > > > > (gdb) help set sysroot > > Set an alternate system root. > > The system root is used to load absolute shared library symbol files. > > For other (relative) files, you can add directories using > > `set solib-search-path'. > > > > You'll have to issue with backslashes on linux though. I don't > > remember if GDB head takes care of converting those to forward > > slashes for you or not. > > > > > > Here's what I see when debugging gdbserver with > > itself on ARM CE 5.0 Pocket PC: > > > > WinMainCRTStartup (hInst=0xf65999ae, hPrevInst=0x0, lpCmdLine=0x2613fed8 L"", nCmdShow=5) > > at /home/pedro/cegcc/trunk/cegcc/src/mingw/crt3.c:35 > > 35 { > > (gdb) info sharedlibrary > > From To Syms Read Shared Object Library > > No ws2.dll > > No coredll.dll.0409.mui > > No coredll.dll > > (gdb) > > > > That is, CE reports relative paths, at least for system dlls. I'm yet > > refresh my memory what happens against a non-system dll. > > > > Okay, just confirmed it. It's the same with non-system dlls. > All reported paths are relative. Here shreloc2.s and shreloc1.sl > are both under /tmp, as well as shreloc, the main application. (this > is a test from gdb's testsuite). > > (gdb) info sharedlibrary > >From To Syms Read Shared Object Library > No shreloc2.sl > No shreloc1.sl > No coredll.dll.0409.mui > No coredll.dll > (gdb) > > So, CE6 behaves differently to CE 5 and lower here. I'm not that > surprised, since the memory model on CE6 was completely revamped > to eliminate the 32MB restrictions. > > > Maybe we can make gdbserver smarter even on CE < 6? I think I > remember that if you had toolhelp.dll on the device, you'd get > absolute paths, but I'm not sure if that's a valid memory I have. > I've added one printf statement to gdbserver/server.c just after where it assembles the library name list. Output on the infamous C++ hello2.exe below. Two out of the three are absolute path names. Not sure why the other one isn't. Is it best to adapt gdbserver for this ? Danny \network\x86> gdbserver :9999 /network/x86/hello2.exe Process /network/x86/hello2.exe created; pid = 92471306 Listening on port 9999 Remote debugging from host 172.17.1.10 Yow { } pavilion: {108} i386-mingw32ce-gdb hello2.exe GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=i386-mingw32ce"... (gdb) target remote ebox:9999 Remote debugging using ebox:9999 [New Thread 92536842] Error while mapping shared library sections: \network\x86\libgcc_s_sjlj-1.dll: No such file or directory. Error while mapping shared library sections: libstdc++-6.dll: No such file or directory. Error while mapping shared library sections: \Windows\coredll.dll: No such file or directory. Symbol file not found for \network\x86\libgcc_s_sjlj-1.dll Symbol file not found for libstdc++-6.dll Symbol file not found for \Windows\coredll.dll WinMainCRTStartup (hInst=0x583000a, hPrevInst=0x0, lpCmdLine=0x2601fc70, nCmdShow=5) at /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/mingw/crt3.c:35 35 { Current language: auto; currently c -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info