From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59130 invoked by alias); 24 Nov 2016 17:47:37 -0000 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 Received: (qmail 59077 invoked by uid 89); 24 Nov 2016 17:47:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=setjmp, H*MI:sk:5834D6E, HX-Greylist:EST, HX-Greylist:0500 X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 24 Nov 2016 17:47:36 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 79EF410A8F0; Thu, 24 Nov 2016 12:47:34 -0500 (EST) From: John Baldwin To: Pedro Alves Cc: Chris Johns , gdb@sourceware.org Subject: Re: gdb-7.12 powerpc-rtems4.12-gdb does not build on FreeBSD. Date: Thu, 24 Nov 2016 17:47:00 -0000 Message-ID: <7134105.CQ6yKBgfxn@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: <3e3f8637-bd0c-4849-0430-1922a737f8f7@redhat.com> References: <5834D6E0.9060601@rtems.org> <2179193.1CJTdt5csh@ralph.baldwin.cx> <3e3f8637-bd0c-4849-0430-1922a737f8f7@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00050.txt.bz2 On Thursday, November 24, 2016 02:59:47 PM Pedro Alves wrote: > On 11/24/2016 02:18 PM, John Baldwin wrote: > > On Thursday, November 24, 2016 12:12:45 PM Pedro Alves wrote: > > >> The PPC sim shouldn't be calling GDB's "error" directly. If it does, > >> then that's should be fixed. There's an "error" method in the > >> host_callback structure (filled in by GDB) that should be used instead. > > > > Ah, the sim defines its own 'error()' routine in misc.c. It also defines its > > own zalloc() and a few other routines, but misc.o isn't included in libsim.a, > > only for specific binaries (it seems to be a stub defined to hold routines > > normally defined in gdb for use in stand-alone programs). Curiously, sim_calls.c > > defines its own zalloc(). I tried adding an error() to sim_calls.c and that > > fixes the build. I modeled it on sim_io_error(): > > Ah, yes, that's indeed simpler than what I was going for (see below, incomplete). > Yours should be able to go to both 7.12 and master. Please send it to gdb-patches. Will do. It may be cleaner long term to use sim-specific error routines as your patch does. > This exposes something else that needs to be done, as long > as the sim is C -- gdb/remote-sim.c:gdb_os_error (which is > what host_callback->error is set to, throws a C++ exception, > and that will want to cross the sim. But that will only work > if the sim is build with -fexceptions (which is the default > on x86_64). So we either need to always build the sim explicitly > with -fexceptions, or we need to longjmp out of the sim instead > of throwing a C++ exception. E.g., wrap calls into the sim > with TRY_SJLJ/CATCH_SJLJ and make gdb_os_error use > throw_exception_sjlj, like we handle longjmp-ing across > readline. Do you think the sims will eventually want to use C++? If so, switching them to build as C++ seems like less work overall as it would solve this while being a step towards that direction. If sims need to stay plain C, then I think I prefer the setjmp/longjmp approach. -- John Baldwin