From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16236 invoked by alias); 20 Mar 2013 17:51:23 -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 16204 invoked by uid 89); 20 Mar 2013 17:51:15 -0000 X-Spam-SWARE-Status: No, score=-3.8 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; Wed, 20 Mar 2013 17:51:12 +0000 Received: from [10.253.80.126] (130.207.218.197) by OARmail.OARCORP.com (192.168.2.2) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 20 Mar 2013 12:51:10 -0500 Message-ID: <5149F70C.3040806@oarcorp.com> Date: Wed, 20 Mar 2013 17:51: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: Mike Frysinger CC: Ralf Corsepius , "gdb@sourceware.org" Subject: Re: [gdb-7.5.91] mips sim fails to build on mingw32 References: <5evvfpyhuvbs9ftm3edxb7na.1363372668425@email.android.com> <51454320.1090000@rtems.org> <5145E9AF.9080401@oarcorp.com> <201303181405.55098.vapier@gentoo.org> In-Reply-To: <201303181405.55098.vapier@gentoo.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-03/txt/msg00049.txt.bz2 On 3/18/2013 1:05 PM, Mike Frysinger wrote: > On Sunday 17 March 2013 12:05:03 Joel Sherrill wrote: >> Comments interspersed but the bottom line is that this is >> an ugly issue where I believe a number of the simulators >> have hard-coded dependencies on dv-sockser.o and do >> not link without it even on CentOS. These sims are: >> >> frv/Makefile.in:CONFIG_DEVICES = dv-sockser.o >> iq2000/Makefile.in:CONFIG_DEVICES = dv-sockser.o >> m32r/Makefile.in:CONFIG_DEVICES = dv-sockser.o >> mn10300/Makefile.in: dv-sockser.o >> sh64/Makefile.in:CONFIG_DEVICES = dv-sockser.o >> >> Plus m68hc11 which does not honor --enable-sim-hardware >> in its configure.ac. Based on the target name, it just enables >> hardware. It appears to be broken in another way. > i'm not sure this is true. the m68hc11 code: > hw_enabled=no > case "${target}" in > m68hc11-*-*|m6811-*-*) > hw_enabled=yes > .... > SIM_AC_OPTION_HARDWARE($hw_enabled,$hw_devices,$hw_extra_devices) > > the common code: > dnl --enable-sim-hardware is for users of the simulator > dnl arg[1] Enable sim-hw by default? ("yes" or "no") > ... > AC_DEFUN([SIM_AC_OPTION_HARDWARE], > > the first arg is the *default* behavior, not the hardcoded behavior. so if you > want to test w/out sim hardware, you have to pass --disable-sim-hardware. Got it. Thanks. >> I have attached a patch which addresses common, mips, bfin >> and makes m68hc11 use the conditional for dv-sockser.o. It >> doesn't make m68hc11 honor --enable-sim-hardware. >> >> mips and bfin build fine with this patch with or without >> --enable-sim-hardware. > well, the default for Blackfin at least is to enable sim hardware :). so > really you have to test with --enable-sim-hardware and --disable-sim-hardware. > SIM_AC_OPTION_HARDWARE(yes,,\ > > for mips, only tx39 defaults to --enable-sim-hardware. the other mips targets > default to --disable-sim-hardware. Thanks for the clarification. >> I don't know what to do about the other targets. My recommendation >> would be: >> >> + m68hc11 -minimum honor --enable-sim-hardware >> + others - if dependency on dv-sockser.o is hard-coded and unavoidable, >> the entire simulator is unsupported on mingw32. > i made the Blackfin sim build on Windows because it was a use case i cared > about :). all of the device models should work fine there too. All I changed was replace the case on mingw to avoid using dv-sockser.o to use the variable from common/acinclude.m4. FYI you have to have bfin as installed to compile the simulator. I suppose this has never been noticed. > it should be easy to update the various sims configure scripts that have > hardware device models that unconditionally use sockser to check the state. > after the call to SIM_AC_OPTION_HARDWARE, you can do: > if test "$sim_hw_p" = yes -a -z "$SIM_DV_SOCKSER_O"; then > case " $sim_hw " in > *" tx3904sio "*) > AC_MSG_ERROR([Sorry, but tx3904sio hardware support is > unavailable for your target. Please use --disable-sim-hardware, or pass a > list of devices to enable that does not include that.]) > esac > fi Done and tested for mips. Can I put a generic message for other targets that "dv-sockser hardware support is unavailable for your target" and let it go at that? Or do I specifically need to list the devices when dv-sockser.o is hard-coded in the Makefile.in? > and then add a TODO comment to each of these failing device modules with > something like "should change code to respect HAVE_DV_SOCKSER". > What would such a message look like and where in the file would it go? > i'd also highlight my opinion that the way the mips sim puts itself together > isn't the right way to go about things. the fact that you can't build a > single mips sim and, at runtime, select the actual target is bad. in glancing > through the code though, i'm not sure this is something that'd be easy to fix > since it seems to be fundamentally baked in :/. I'm not pulling that thread but for RTEMS we build both mips-rtems and mipstx39-rtems so this is pretty obvious to us. :) >> FWIW the host pattern is mingw32 for the work around and >> mingw64 may have this as well. I have no way to test this. > i've never tested mingw64 myself. i think it's safe to assume that the > failure is common to all Windows targets, so using *mingw* as the pattern is > sane. Got it. >>> But ... this provides further insights: >>> >>> I configure using "default" simulator flags: >>> --enable-sim >>> >>> You configure using "exotic" simulator flags: >>> --enable-sim --enable-sim-hardware --enable-timebase --enable-sim-trace >>> >>> Why you're using them, I don't know. >> Very simple. configure options are supposed to be used or ignored >> by each component. That is by definition. > yeah, i didn't see anything unusual in your configure flag selection. seemed > perfectly reasonable to me :). Now I am testing with explicit --enable-sim-hardware and --disable-sim-hardware. >>> => The patch is wrong and should be reverted. The configuration magic to >>> pull in dv-socksers.o should be reworked and likely needs to be keyed to >>> -enable-sim-hardware. >> Agreed. This is a bug in common/acinclude.m4 and (possibly) the >> Makefile.in for the actual simulators. > i don't generally buy into the "revert revert revert" mentality. if you're > working on a real fix, let's go for it. I am getting close. Something should show up shortly. >> --- gdb-7.5.91-virgin/sim/common/acinclude.m4 >> +++ gdb-7.5.91/sim/common/acinclude.m4 >> @@ -647,6 +647,16 @@ >> *) sim_hw="$sim_hw $i" ; sim_hw_objs="$sim_hw_objs dv-$i.o";; >> esac >> done >> + # mingw32 does not support sockser >> + SIM_DV_SOCKSER_O="" > indentation is off by one space here Fixed > -mike -- 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