From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18997 invoked by alias); 14 Jun 2009 13:56:48 -0000 Received: (qmail 18989 invoked by uid 22791); 14 Jun 2009 13:56:47 -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; Sun, 14 Jun 2009 13:56:41 +0000 Received: (qmail 12685 invoked from network); 14 Jun 2009 13:55:19 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Jun 2009 13:55:19 -0000 From: Pedro Alves To: danny.backx@scarlet.be Subject: Re: Patch : gdbserver get_image_name on CE Date: Sun, 14 Jun 2009 13:56:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <1244903385.20290.9.camel@pavilion> <200906131908.58817.pedro@codesourcery.com> <1244968481.20290.53.camel@pavilion> In-Reply-To: <1244968481.20290.53.camel@pavilion> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906141456.42233.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-06/txt/msg00370.txt.bz2 On Sunday 14 June 2009 09:34:41, Danny Backx wrote: > Your comment about I need to address the setjmp issue is correct. I need > to find the cause though. This part of the patch certainly doesn't > belong in gdb's sources. > But it's still in discussion phase, isn't it ? It sure is. > More comments ? Should the INT3 comment go away ? I feel that the code > is under-commented at times, but this one may be somewhat overdone :-) Yes. int3 is the standard x86 breakpoint op. It is the same on Windows9x/NT, on linux (see linux-x86-low.c), and pretty much every x86 OS. win32-i386-low.c just didn't register a breakpoint instruction because Windodws gdbserver itself didn't need to insert breakpoints (gdb takes care of regular user breakpoints by issuing regular memory reads/writes) --- on desktop Windows, the OS always reports a magic "initial breakpoint hit" after reporting all threads and dlls loaded in the process. On Windows CE however, we fake it ourselves. That's this code in win32-low.c: ... #ifdef _WIN32_WCE if (!attaching) { /* Windows CE doesn't set the initial breakpoint automatically like the desktop versions of Windows do. We add it explicitly here. It will be removed as soon as it is hit. */ set_breakpoint_at ((CORE_ADDR) (long) current_event.u .CreateProcessInfo.lpStartAddress, auto_delete_breakpoint); } #endif ... #ifdef _WIN32_WCE /* Remove the initial breakpoint. */ check_breakpoints ((CORE_ADDR) (long) current_event .u.Exception.ExceptionRecord.ExceptionAddress); #endif -- Pedro Alves