From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14689 invoked by alias); 29 Mar 2013 16:26:03 -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 14645 invoked by uid 89); 29 Mar 2013 16:25:50 -0000 X-Spam-SWARE-Status: No, score=-9.7 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 29 Mar 2013 16:25:47 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 8A90F33DBF1; Fri, 29 Mar 2013 16:25:45 +0000 (UTC) From: Mike Frysinger To: Joel Sherrill Subject: Re: m32r sim was Re: one week to gdb-7.6 release? Date: Fri, 29 Mar 2013 17:18:00 -0000 User-Agent: KMail/1.13.7 (Linux/3.7.6; KDE/4.6.5; x86_64; ; ) Cc: Ralf Corsepius , Joel Brobecker , Eli Zaretskii , "gdb-patches@sourceware.org" , "palves@redhat.com" , "jan.kratochvil@redhat.com" References: <20130320160032.GC5447@adacore.com> <51553AA8.8020705@rtems.org> <5155A93E.3050509@oarcorp.com> In-Reply-To: <5155A93E.3050509@oarcorp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2345571.0YHnXJXVKb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201303291230.37045.vapier@gentoo.org> X-Virus-Found: No X-SW-Source: 2013-03/txt/msg01116.txt.bz2 --nextPart2345571.0YHnXJXVKb Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-length: 1848 On Friday 29 March 2013 10:46:22 Joel Sherrill wrote: > On 3/29/2013 1:54 AM, Ralf Corsepius wrote: > > Using the same set of configuration options, I have been using for > > gdb-7.5.x, all targets build fine on Linux. > >=20 > > However, there is a new breakdown for the m32r on > > mingw32-w64-{x86_64,i386}: > >=20 > > ..../configure --build=3Di386-pc-linux-gnu \ > > --host=3Dx86_64-w64-mingw32 --target=3Dm32r-rtems4.11 > > --enable-sim [...] \ > > ... > > checking how to recognize dependent libraries... configure: error: > > Sorry, but hardware support in this simulator unconditionally > > relies on dv-sockser.o which is unavailable for your host. Please fix > > this simulator. > > ... > >=20 > > As gdb-7.5.x built fine with the same configuration, this to me > > qualifies as a regression - Or is this just a latent, so far silently > > accepted, but dysfunctional part being revealed by the new configuration > > magic? >=20 > Looking back at 7.5.91, I see that m32r unconditionally uses > dv-sockser.o and > I don't know how it built before. two reasons: - it never defined HAVE_DV_SOCKSER - it adds dv-sockser.o in Makefile.in only to then clear the variable so it had all the framework for the code, but never actually enabled it :).= =20=20 your patch actually fixed that part. > The references to dv-sockser.o methods appear to be properly > conditionalized in the code. So it is the Makefile.in and our > interpretation that the simulated > hardware should be "always on" versus "yes enabled" by default. >=20 > Attached is an untested patch. you should also update m32r/tconfig.in and remove the 3 lines related to #i= f=20 0/HAVE_DV_SOCKSER. also, you'll need to apply the same fix to frv. it too has proper=20 HAVE_DV_SOCKSER conditionals, and explicitly lists it in Makefile.in, only = to=20 later disable it. -mike --nextPart2345571.0YHnXJXVKb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJRVcGsAAoJEEFjO5/oN/WBWLMP/3AxTbUd+kLSiM60ikWENlCl xkD75WWHBem7yVZ8fl55CxIwAls/Rnz9IWkDVJ3RkFYeQZrB6D+b5j5m/xsv08j+ lZFqmA58rurgKYKsJ4d5MSkpS0S4w5BzLcaJndDlhXo8xyC+ZSEFY8utfuw0ns95 Ku8JsOZ3TaoAyTIpNhE12AJXpJx7vYBlA6cnQ5VXqygdUWq8GF34qa1Dw/PlZqWB GBnEX/YDgD7w8jsBcsuou2gyg7AI2JSOg2W2mHoqghonob4Apkp9WOEyz9JpNZcg cDUi3Tlqgwth2TIcA3eEeoD49NNKP+5+xWnmXVsMaN0NWrQ+fR4F8k5j7ureeOUJ IzO5Y7d1QTvRZ4Bp/sKCO7dtwJYD0GU3WyXMtWavyuJ6/OjiWZmcIjIdXbnEOajH 2u0AqoZbMiavTkl/ttnHiVZKiOSACsk9p4qaDseIr5nccV6j7k3vDRT3VgMMYtYK Zfg0vqN4f2RH2f48JjWTD/EzbbinV0CcBJx1S6wOy6rJoZabbkMpwv+5RTCxjTRJ eGgDRcK7gHkW9VocODg9DUUHokIiDUjIo1rCdiz37WkHKL/B3T7TsFkuSI9IKmSt TL0cdXyGIYB+C1E2o+V8nuAOZyPSPGsu6q7yhsScGGl+VPOx89Y6L8TNVzG4WImB iwE0jaqyNZ/ZpqwcsgMe =M8bC -----END PGP SIGNATURE----- --nextPart2345571.0YHnXJXVKb--