From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13046 invoked by alias); 3 Feb 2010 19:39:49 -0000 Received: (qmail 13036 invoked by uid 22791); 3 Feb 2010 19:39:48 -0000 X-Spam-Check-By: sourceware.org Received: from pool-173-76-58-83.bstnma.fios.verizon.net (HELO cgf.cx) (173.76.58.83) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Feb 2010 19:39:44 +0000 Received: from ednor.cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id 728AD13C0C7; Wed, 3 Feb 2010 14:39:34 -0500 (EST) Received: by ednor.cgf.cx (Postfix, from userid 201) id 6C5782B35A; Wed, 3 Feb 2010 14:39:34 -0500 (EST) Date: Wed, 03 Feb 2010 19:39:00 -0000 From: Christopher Faylor To: Kai Tietz , Chris Sutcliffe , gdb@sourceware.org Subject: Re: [gdb-7.1] 10 days to branching... Message-ID: <20100203193934.GA12020@ednor.casa.cgf.cx> Mail-Followup-To: Kai Tietz , Chris Sutcliffe , gdb@sourceware.org References: <20100201081928.GA9204@adacore.com> <2bf229d31002010809o2cb8760du9a52c9b996e91c56@mail.gmail.com> <20100202041644.GN8831@adacore.com> <2bf229d31002020435v7c804a91w9c74b7ed2eff4314@mail.gmail.com> <90baa01f1002020802icf6aa90oa28466ed7cf3ae29@mail.gmail.com> <20100202224349.GA31505@ednor.casa.cgf.cx> <90baa01f1002030019n531a35der5c36161c78373f97@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90baa01f1002030019n531a35der5c36161c78373f97@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-02/txt/msg00020.txt.bz2 On Wed, Feb 03, 2010 at 09:19:57AM +0100, Kai Tietz wrote: >2010/2/2 Christopher Faylor : >> On Tue, Feb 02, 2010 at 05:02:11PM +0100, Kai Tietz wrote: >>>2010/2/2 Chris Sutcliffe : >>>>> I don't know - I had never heard of anyone doing this kind of build >>>>> before: ?From what I can tell, you are building a MinGW debugger using >>>>> a cygwin compiler. ?If no one answered, it's probably because no one >>>>> has anything to say (including: "that ought to work"). ?Have you tried >>>>> using a MinGW compiler instead? >>>> >>>> For the mingw-w64 build, I did indeed build from within Cygwin using >>>> the mingw-w64 cross compiling toolchain provided by the mingw-w64 >>>> project. ?For the MinGW32 binary I built it using MSYS and the MinGW >>>> compiler. ?In both cases this is the method I used to the build the >>>> 7.0.1 binary. >>> >>>Yes, I can confirm that buiding on a cygwin host by a valid >>>cross-compiler is working nicely. I justed tried, and for me it still >>>works. Possibly an issue about passed configure options? >>> >>>Just one point I found today. The new break-point handling seems to >>>have problems in certain ways for me (at least on win32 versions). I >>>get in case of setting breakpoints in Obj-C always the assertation >>>'set_raw_breakpoint: Assertation sal.pspace != NULL' failed'. This is >>>new and is somehow related to recent enhancements to breakpoint >>>handling. >> >> I don't see anything like this when setting breakpoints in a c++ >> app. ?I'm not familiar with objective-C but I believe I managed to >> build a simple hello world app. ?I set a breakpoint in main with >> no problem. >> >> This is with a i686-cygwin gdb built on linux. >> >> cgf >> > >Hallo Christopher, > >well for basic Object-C apps, I don't see the issue, too. For C and >C++ I couldn't reproduce this. This seems to happen on setting of >breakpoint on Object-C methods in shared object. >I tried two different ways to set breakpoint. First variant is before >starting (as pending breakpoint). This works a long as the DLL isn't >loaded. As soon as it is, the gdb gives the above mentioned >asseration. Second variant is, starting application and stopping it by >Crtl-C, setting breakpoint. Here the problem is shown directly. >I can provide the application I have (it is an about 50MB binary) and >owned by the company I am working, but it seems that in such scenario >the pspace remains NULL. Any possibility that you can confirm whether this is a windows-only problem? I think the only way to do that is to provide a test case. cgf