From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13854 invoked by alias); 24 Mar 2013 02:12:16 -0000 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 Received: (qmail 13816 invoked by uid 89); 24 Mar 2013 02:12:07 -0000 X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from oarmail.oarcorp.com (HELO OARmail.OARCORP.com) (67.63.146.244) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sun, 24 Mar 2013 02:12:04 +0000 Received: from [192.168.0.14] (24.96.88.41) by OARmail.OARCORP.com (192.168.2.2) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sat, 23 Mar 2013 21:12:02 -0500 Message-ID: <514E60F0.3030406@oarcorp.com> Date: Sun, 24 Mar 2013 05:39:00 -0000 From: Joel Sherrill User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Hans-Peter Nilsson CC: "gdb-patches@sourceware.org" Subject: Re: Recent simulator patches broke many sims References: <201303240038.r2O0cTSq009264@ignucius.se.axis.com> In-Reply-To: <201303240038.r2O0cTSq009264@ignucius.se.axis.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-03/txt/msg00887.txt.bz2 On 3/23/2013 7:38 PM, Hans-Peter Nilsson wrote: >> From: Joel Sherrill >> Date: Sat, 23 Mar 2013 23:49:18 +0100 >> And built successfully when configured like this: >> >> ../gdb/configure --target=frv-elf --prefix=/home/joel/test-gdb/install >> --enable-sim-hardware --enable-sim --enable-sim-trace > "gdb" as in toplevel from a gdb checkout, I presume. > (If from the gdb subdir I guess you wouldn't get very far.) > Is that why you have to add those options? I added those options because that is the combination that initially tripped the failure months ago. Then last week someone spotted that mingw failed to build. Mike Frysinger and I have been trying to come up with a configure solution that handles mingw not supporting dv-sockser.o and some simulators always requiring it. > One major difference is that I use the toplevel configure after > a checkout of *the "sim" CVS module*, so not much of gdb there, > actually just MAINTAINERS and version.in. I don't think that's really much of an issue. Except to increase my build time. I have a fix in my local tree and posted it to the list. Here is my test plan. I regenerated all of the sim directories where configure.ac includes acinclude.m4. That resulted in the following set of modified files on my working git branch: # modified: bfin/configure # modified: common/acinclude.m4 # modified: cris/configure # modified: frv/configure # modified: iq2000/configure # modified: lm32/configure # modified: m32r/configure # modified: m68hc11/configure # modified: mips/configure # modified: mn10300/configure # modified: sh64/configure Based on that, I put together the following list of targets: bfin-elf cris-elf frv-elf iq2000-elf lm32-elf m32r-elfle m68hc11-elf mips-elf mipstx93-elf mn10300-elf sh64-elf For each of those targets, I will build with no sim-hardware argument, --enable-sim-hardware, and --disable-sim-hardware. If the configure and make complete successfully, I will run make check. Any other suggestions on how to test this? >> I can hop on IRC if you give me a channel so we can work through >> this quickly. Other forms of chat are OK also. I want to run this down >> so a release can happen. > Sometimes I'm at irc.oftc.net#gcc > > brgds, H-P -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherrill@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985