From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28890 invoked by alias); 14 Jun 2009 09:48:36 -0000 Received: (qmail 28882 invoked by uid 22791); 14 Jun 2009 09:48:36 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_55,RCVD_IN_DNSWL_LOW,SPF_PASS,URIBL_RHS_DOB 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; Sun, 14 Jun 2009 09:48:23 +0000 Received: from [172.17.1.10] (ip-81-11-255-63.dsl.scarlet.be [81.11.255.63]) by hel.is.scarlet.be (8.14.2/8.14.2) with ESMTP id n5E9m71m032169; Sun, 14 Jun 2009 11:48:08 +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: <1244969225.20290.59.camel@pavilion> References: <1244903385.20290.9.camel@pavilion> <200906131905.30933.pedro@codesourcery.com> <1244969225.20290.59.camel@pavilion> Content-Type: text/plain Date: Sun, 14 Jun 2009 09:48:00 -0000 Message-Id: <1244972893.20290.71.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-06/txt/msg00369.txt.bz2 On Sun, 2009-06-14 at 10:47 +0200, Danny Backx wrote: > On Sat, 2009-06-13 at 19:05 +0100, Pedro Alves wrote: > > > 2. Handle a case where the inferior refuses to start. See the > > > code after WaitForDebugEvent in win32-low.c . > > > > This is quite mystifying. Do you have more details on this? > > Not yet, but as I said in the other message, the a simple setjmp demo > application is an example. Other cases I've seen were with invalid > requirements to a DLL (use of an API that was not in the DLL). On a > PocketPC, this causes a dialog to pop up. On Windows Embedded CE the > application appears just not to start up. > > > > 3. Setjmp won't work on this platform, I've "#if 0"-ed it out. > > > Clearly not the right solution. Comment please. > > > > What does "won't work on this platform" mean? If longjmp > > doesn't work, then you probably have a bug in your > > headers or import libs? I'd suspect _JBLEN in the > > mingw headers. > > I've been thinking about that too, I'll try to debug this but that's > hard with no debugger. The cause turns out to be the obvious one, if you read the above well. The setjmp call is documented on MSDN but my experiments show that the coredll.dll doesn't offer it on the platform I'm using. Therefore, an application that tries to fetch it from the DLL will simply not start up. I've looked at the gdbserver code. The only two reasons I see for using setjmp/longjmp are : - to call kill_inferior () if you're beyond some point - to end up at the "restart:" point I see three options : - write a setjmp replacement, put it in utils.c, and leave the rest of the code as is. - remove setjmp/longjmp and just exit in that one place where longjmp is called - improve the code so errors are always treated well without relying on longjmp The last one is not something I'd like to start. My current code basically implements the second one, I'm not sure what would be going wrong if this would be implemented generally. A final note : detecting this situation automatically at configure time is not obvious because of the cross-compile. Opinions ? Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info