From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26979 invoked by alias); 1 Jul 2009 18:52:29 -0000 Received: (qmail 26970 invoked by uid 22791); 1 Jul 2009 18:52:29 -0000 X-SWARE-Spam-Status: No, hits=-2.4 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, 01 Jul 2009 18:52:19 +0000 Received: (qmail 7054 invoked from network); 1 Jul 2009 18:52:18 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Jul 2009 18:52:18 -0000 From: Pedro Alves To: danny.backx@scarlet.be Subject: Re: Patch : gdbserver get_image_name on CE Date: Wed, 01 Jul 2009 18:52:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <1244903385.20290.9.camel@pavilion> <200906302258.00604.pedro@codesourcery.com> <1246473648.15871.201.camel@pavilion> In-Reply-To: <1246473648.15871.201.camel@pavilion> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907011953.32584.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-07/txt/msg00035.txt.bz2 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. >=20 > You'll probably need to read that five times to understand it :-) Nope, I got it the first time. :-) >=20 > 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 >=20 > This could be due to=20 > - an invalid .def file > - a .def file that's valid for one distribution of WinCE but not for > =A0 another (read: differences between CE versions) >=20 > 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.=20 >=20 > Furthermore : none of the debug API's work either, gdbserver really gets > not a single sensible signal from the underlying process. >=20 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 :-) --=20 Pedro Alves