From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20377 invoked by alias); 12 Aug 2009 15:36:22 -0000 Received: (qmail 20237 invoked by uid 22791); 12 Aug 2009 15:36:20 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Aug 2009 15:36:12 +0000 Received: (qmail 4956 invoked from network); 12 Aug 2009 15:36:09 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Aug 2009 15:36:09 -0000 From: Pedro Alves To: danny.backx@scarlet.be Subject: Re: Ping (Re: Patch : gdbserver get_image_name on CE) Date: Wed, 12 Aug 2009 22:33:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <1250021102.5537.1123.camel@pavilion> <200908121511.20428.pedro@codesourcery.com> <1250090270.5537.1138.camel@pavilion> In-Reply-To: <1250090270.5537.1138.camel@pavilion> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200908121636.13714.pedro@codesourcery.com> X-IsSubscribed: yes 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-08/txt/msg00171.txt.bz2 On Wednesday 12 August 2009 16:17:50, Danny Backx wrote: > (gdb) info share > >From =A0 =A0 =A0 =A0To =A0 =A0 =A0 =A0 =A0Syms Read =A0 Shared Object Li= brary > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 No =A0 =A0 =A0 =A0 =A0\Wi= ndows\iphlpapi.dll > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 No =A0 =A0 =A0 =A0 =A0\Wi= ndows\ws2.dll > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 No =A0 =A0 =A0 =A0 =A0\ne= twork\x86\ace\libgcc_s_sjlj-1.dll > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 No =A0 =A0 =A0 =A0 =A0\ne= twork\x86\ace\libstdc++-6.dll > 0x41f21000 =A00x420d9744 =A0Yes =A0 =A0 =A0 =A0 libace.dll > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 No =A0 =A0 =A0 =A0 =A0\Wi= ndows\coredll.dll > (gdb)=20 >=20 > > Does this > > ReadProcessMemory problem still exist with a fixed dll? =A0Did you ever > > see this problem with another dll? Well, both these dlls have considerable size, they're both written in C++, and they were both generated from your toolchain. Maybe that's a coincidence, but maybe not. I don't know how other folks tend to catch these issues, but one thing I would do would be to either remove things from the dll until I could reproduce it with a *minimal* dll, or go the other way around, start with a minimal dll that doesn't have the problem, and add things until the problem appears. There's the other issue that CE isn't reporting full paths for these dlls. It doesn't look like a coincidence to me. > Yes, and yes. See above. The one that shows it in this output is not the > DLL that had that other problem (that was libstdc++-6.dll). >=20 > > =A0 I'm very relunctant to this > > fix without understanding it fully, and without having seen it > > trigger with a sane dll, and not really understanding why some dlls > > cause it and other don't, even though they're apparently built > > the exact same way --- not because I'm hard headed, but because > > these workarounds tend to mask other real problems. =A0From what > > I've heard so far, this only triggered on that broken dll. =A0I wonder = if > > anyone has tried loading an application with a dll that triggers > > this into MSFT's debugger, and see if it reads the dll name correctly. >=20 > I understand your point. But they're separate issues. I do have to admit > I don't know what's causing it. Don't you want to know what is? > I'll look into your code style comments and submit a new patch, unless > you want other information before I start going down that path. I give up. Let's follow this road then. --=20 Pedro Alves