From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9216 invoked by alias); 27 Feb 2013 17:20:29 -0000 Received: (qmail 9185 invoked by uid 22791); 27 Feb 2013 17:20:24 -0000 X-SWARE-Spam-Status: No, hits=-8.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_GJ X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Feb 2013 17:20:17 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1RHKFed011483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Feb 2013 12:20:17 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1RHKEA3006225 for ; Wed, 27 Feb 2013 12:20:15 -0500 Message-ID: <512E404E.6070504@redhat.com> Date: Wed, 27 Feb 2013 17:20:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [patch]: Replace stryoul call to fetch address References: <20130227164419.GA16975@calimero.vinschen.de> In-Reply-To: <20130227164419.GA16975@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: 2013-02/txt/msg00691.txt.bz2 On 02/27/2013 04:44 PM, Corinna Vinschen wrote: > Hi, Hi, > > here's a small patch which will help along building GDB on the (not > yet finished) x86_64 Cygwin. > > Mostly these are just a few casts, and tweaks to the printf format > strings, so that the argument and the format matches all three cases: > > - i686 > - x86_64 LLP (Mingw, native Windows) > - x86_64 LP (Cygwin) > > The most important part of the patch is in handle_output_debug_string, > though. The address for the context information is read from the string > using the strtoul function. This works fine for a 32 bit GDB, and it > also works fine for a 64 bit Cygwin GDB. It does not work for a 64 bit > Mingw GDB debugging a 64 bit Cygwin application, though. Therefore I > replaced the strtoul with a call to string_to_core_addr. IIRC, the matching Cygwin code that that special Cygwin signals handling was never implemented, or it was disabled on Cygwin, or some such, and that gdb bits is actually causing trouble -- see http://sourceware.org/ml/gdb-patches/2013-02/msg00122.html. We should just zap it all. > Apart from that there's more required to get GDB working on Cygwin, > apparently, but I thought the below patch is simple enough to go in > already. One thing that comes to mind is I think we'll need to have separate mingw64/cygwin64 osabis. Currently, mingw 32/64 use GDB_OSABI_CYGWIN, and that limps along, but with LP vs LLP, that won't work. We'll need a way to distinguish Cygwin vs native Windows binaries. Probably by checking for cygwin.dll in the dll import list? Another point where that'd be good is in step-over-longjmp support (gdbarch_get_longjmp_target). IIRC, the offset of PC within the jmpbuf of msvcrt.dll is not the same as Cygwin's (32-bit; dunno about 64-bit). > > Ok to apply? > DWORD err = GetLastError (); > - warning (_("SuspendThread failed. (winerr %d)"), > + warning (_("SuspendThread failed. (winerr %u)"), > (int) err); This one doesn't look right. %d matches the cast to signed int. I think you wanted the converse. %u and (unsigned). Otherwise looks fine to me. -- Pedro Alves