From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19976 invoked by alias); 1 Jul 2009 19:12:28 -0000 Received: (qmail 19965 invoked by uid 22791); 1 Jul 2009 19:12:27 -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 eir.is.scarlet.be (HELO eir.is.scarlet.be) (193.74.71.27) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Jul 2009 19:12:18 +0000 Received: from [172.17.1.10] (ip-81-11-242-24.dsl.scarlet.be [81.11.242.24]) by eir.is.scarlet.be (8.14.2/8.14.2) with ESMTP id n61JC3Dg020639; Wed, 1 Jul 2009 21:12:03 +0200 Subject: 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: <200907011953.32584.pedro@codesourcery.com> References: <1244903385.20290.9.camel@pavilion> <200906302258.00604.pedro@codesourcery.com> <1246473648.15871.201.camel@pavilion> <200907011953.32584.pedro@codesourcery.com> Content-Type: text/plain Date: Wed, 01 Jul 2009 19:12:00 -0000 Message-Id: <1246475531.15871.252.camel@pavilion> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-DCC-scarlet.be-Metrics: eir 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/msg00037.txt.bz2 On Wed, 2009-07-01 at 19:53 +0100, Pedro Alves wrote: > On Wednesday 01 July 2009 19:40:48, Danny Backx wrote: > > I am certain that this happens when you create an executable which > > attempts to get an API from a DLL by name, if the API happens not to be > > in the DLL. > > > > You'll probably need to read that five times to understand it :-) > > Nope, I got it the first time. :-) > > > > > If the development environment is wrong in this way : > > - a .def file was used to create a .dll.a file > > - the .def file implements an api that's not actually in the DLL > > > > This could be due to > > - an invalid .def file > > - a .def file that's valid for one distribution of WinCE but not for > > another (read: differences between CE versions) > > > > Anyway. What happens is the executable appears to start (CreateProcess > > returns valid results), then the loader kicks in and fails. This is > > where I have verified that you will get this result. > > > > Furthermore : none of the debug API's work either, gdbserver really gets > > not a single sensible signal from the underlying process. > > > > What I was interested in knowing, was if loading a similarly faulty > dll (not the main executable) triggers the same issue. Both in the > case where the app is "linked" to it (gcc -o foo foo.c -lbaddll) --- > I expect so, and in the case where LoadLibrary is used to pull in a > bad dll. If the latter case triggers the same "lost connection to > inferior" error, then you have yourself a kernel bug. > > You'll probably need to read that five times to understand it :-) Hmm :-) I verified the LoadLibrary case. I believe the LoadLibrary call returned the right error message (ERROR_DLL_INIT_FAILED, 1114L). I don't have the evidence of that test any more though. Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info