From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15184 invoked by alias); 12 Aug 2009 15:16:58 -0000 Received: (qmail 15116 invoked by uid 22791); 12 Aug 2009 15:16:56 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_55,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: sourceware.org Received: from sif.is.scarlet.be (HELO sif.is.scarlet.be) (193.74.71.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Aug 2009 15:16:48 +0000 Received: from [172.17.1.10] (ip-81-11-238-76.dsl.scarlet.be [81.11.238.76]) by sif.is.scarlet.be (8.14.2/8.14.2) with ESMTP id n7CFGU37021096; Wed, 12 Aug 2009 17:16:31 +0200 Subject: Re: Ping (Re: Patch : gdbserver get_image_name on CE) From: Danny Backx Reply-To: danny.backx@scarlet.be To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: <200908121511.20428.pedro@codesourcery.com> References: <1250021102.5537.1123.camel@pavilion> <200908121511.20428.pedro@codesourcery.com> Content-Type: text/plain Date: Wed, 12 Aug 2009 15:36:00 -0000 Message-Id: <1250090270.5537.1138.camel@pavilion> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-DCC-scarlet.be-Metrics: sif 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-08/txt/msg00170.txt.bz2 On Wed, 2009-08-12 at 15:11 +0100, Pedro Alves wrote: > Sorry, I'm quite behind on reading cegcc-devel@. Do you now have a > fully working non-broken libstdc++ dll (the dll that triggered this > problem)? IIUC from the binutils posts, the runtime loader was ending > up doing things it shouldn't do to the dll image in memory. Summary on the "broken DLL" issue : in the gcc port, I wasn't emitting the type info for the function symbols. This made binutils (dlltool) behave in the wrong way, which in turn resulted in relocations that didn't happen right. Now that this is understood, I don't see how this can have influence on the gdbserver/ReadProcessMemory issue. But before understanding this, your question was certainly valid. But in order to be more certain, here's output I created just now of an unfixed gdbserver : (gdb) info share >From To Syms Read Shared Object Library No \Windows\iphlpapi.dll No \Windows\ws2.dll No \network\x86\ace\libgcc_s_sjlj-1.dll No \network\x86\ace\libstdc++-6.dll No li No \Windows\coredll.dll (gdb) Here is output with my fix : (gdb) info share >From To Syms Read Shared Object Library No \Windows\iphlpapi.dll No \Windows\ws2.dll No \network\x86\ace\libgcc_s_sjlj-1.dll No \network\x86\ace\libstdc++-6.dll 0x41f21000 0x420d9744 Yes libace.dll No \Windows\coredll.dll (gdb) > Does this > ReadProcessMemory problem still exist with a fixed dll? Did you ever > see this problem with another dll? 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). > 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. From what > I've heard so far, this only triggered on that broken dll. I 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. I understand your point. But they're separate issues. I do have to admit I don't know what's causing it. 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. Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info