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

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

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