From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20174 invoked by alias); 27 Feb 2013 20:06:03 -0000 Received: (qmail 20156 invoked by uid 22791); 27 Feb 2013 20:05:59 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mho-04-ewr.mailhop.org (HELO mho-02-ewr.mailhop.org) (204.13.248.74) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Feb 2013 20:05:54 +0000 Received: from pool-108-20-146-82.bstnma.fios.verizon.net ([108.20.146.82] helo=cgf.cx) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1UAnGE-000Ao0-96 for gdb-patches@sourceware.org; Wed, 27 Feb 2013 20:05:54 +0000 Received: from localhost (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id C334B880291 for ; Wed, 27 Feb 2013 15:05:53 -0500 (EST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18YZxl/XceYYlBZ43wKOl8D Date: Wed, 27 Feb 2013 20:29:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org Subject: Re: [patch]: Replace stryoul call to fetch address Message-ID: <20130227200553.GB5873@ednor.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org References: <20130227164419.GA16975@calimero.vinschen.de> <512E404E.6070504@redhat.com> <20130227200303.GA5873@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130227200303.GA5873@ednor.casa.cgf.cx> User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00711.txt.bz2 On Wed, Feb 27, 2013 at 03:03:03PM -0500, Christopher Faylor wrote: >On Wed, Feb 27, 2013 at 05:20:14PM +0000, Pedro Alves wrote: >>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. > >I didn't take from that patch that it was causing problems. > >The signal code is expected to work. Just to be a little less terse: The quoted email is me commenting on the fact that someone submitted a patch which "#if 0"ed some code. I was commenting on the '#if 0' not on the fact that cygwin's signal handling with gdb is broken. AFAIK, it is working. If it isn't working then I would never suggest that ripping out code was the right solution. cgf