From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5124 invoked by alias); 27 Feb 2013 19:14:58 -0000 Received: (qmail 5108 invoked by uid 22791); 27 Feb 2013 19:14:56 -0000 X-SWARE-Spam-Status: No, hits=-7.9 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_CG,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 19:14:48 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1RJEmS0027671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Feb 2013 14:14:48 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r1RJElmK025219 for ; Wed, 27 Feb 2013 14:14:47 -0500 Message-ID: <512E5B26.7050104@redhat.com> Date: Wed, 27 Feb 2013 19:40: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> <512E404E.6070504@redhat.com> <20130227183805.GA30418@calimero.vinschen.de> In-Reply-To: <20130227183805.GA30418@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/msg00704.txt.bz2 On 02/27/2013 06:38 PM, Corinna Vinschen wrote: >> 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 don't know exactly. Probably cgf would be able to answer this > better than me. I think I recall some email from him long about about the cygwin side of that, but he wasn't against removing these bits of on the gdb end in that url above, so... > In fact I have a SEGV right now which I still have > to investigate, but I'm working on GDB only as a side job. Sure. I just meant to point out that that's exactly the code you're touching. ;-) >> 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. > > Why not? The only difference between the x86_64 Cygwin and Mingw ABI > is the sizeof long. And that's noted in the dwarf debug info. Not every use use of the target's "long" goes through the debug info. I see uses of gdbarch_long_bit and builtin_long in the expression machinery, for example in c-exp.y, for handling integer constants, or in eval.c, for type promotion. x64's long is fixed to 32-bit in amd64_windows_init_abi. > Apart > from a strange crash when trying to load stripped executables, I'm > using a x86_64 Mingw GDB to debug x86_64 Cygwin DLL and binaries. > I'm not sure this single difference justifies distinct OSABIs. Sure, we'll limp along. But there are cases that bypass debug info. A distinct OSABI seems like the proper mechanism to me. Time will tell. ;-) > >> We'll need a way to distinguish Cygwin vs native Windows >> binaries. Probably by checking for cygwin.dll in the dll import list? > > A check for cygwin1.dll is already done in windows_make_so. Yeah, though that's only after the dll is loaded. I was thinking of looking at import list, when the executable is loaded in gdb, hence before the program is run. > >> 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). > > Cygwin 64 bit uses the same jmpbuf layout as native Windows. Only > two members are used differently, but those should not be used by > GDB anyway. OK. > Ok, I apply it then with only the int changed to unsigned. Thanks. -- Pedro Alves