From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32380 invoked by alias); 27 Feb 2013 19:43:08 -0000 Received: (qmail 30496 invoked by uid 22791); 27 Feb 2013 19:42:44 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Wed, 27 Feb 2013 19:42:38 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 5DA06520243; Wed, 27 Feb 2013 20:42:35 +0100 (CET) Date: Wed, 27 Feb 2013 19:53:00 -0000 From: Corinna Vinschen To: gdb-patches@sourceware.org Subject: Re: [patch]: Replace stryoul call to fetch address Message-ID: <20130227194235.GB30418@calimero.vinschen.de> Reply-To: gdb-patches@sourceware.org Mail-Followup-To: gdb-patches@sourceware.org References: <20130227164419.GA16975@calimero.vinschen.de> <512E404E.6070504@redhat.com> <20130227183805.GA30418@calimero.vinschen.de> <512E5B26.7050104@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <512E5B26.7050104@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2013-02/txt/msg00707.txt.bz2 On Feb 27 19:14, Pedro Alves wrote: > 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... Chris, ping? > > 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. ;-) The SEGV occurs in exception.c, function throw_exception, though. The `*current_catcher->exception = exception;' assignment crashes because current_catcher->exception is NULL. I don't understand yet why it's NULL, and why the throw_exception function doesn't test this before trying to write *current_catcher->exception. > >> 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. Oh, hmm. I didn't notice that. So, well, maybe... > > 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. ;-) ...you're right. I just don't know if I'm really the right person to do that. > [...] > > Ok, I apply it then with only the int changed to unsigned. > > Thanks. Applied. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat