Re: [gdb-7.5.91] mips sim fails to build on mingw32

Joel Sherrill
2013-03-20T17:51:23Z

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