Currently ports have to call SIM_AC_OPTION_ENVIRONMENT explicitly in
order to make the configure flag available. There's no real reason
to not allow this flag for all ports, so move it to the common sim
macro. This way we get standard behavior across all ports too.
Currently ports have to call SIM_AC_OPTION_INLINE explicitly in order
to make the configure flag available. There's no real reason to not
allow this flag for all ports, so move it to the common sim macro.
This way we get standard behavior across all ports too.
The --enable-sim-hostendian flag was purely so people had an escape route
for when cross-compiling. This is because historically, AC_C_BIGENDIAN
did not work in those cases. That was fixed a while ago though, so we can
require that macro everywhere now and simplify a good bit of code.
Rather than re-invent endian defines, as well as maintain our own list
of OS & arch-specific includes, punt all that logic in favor of the bfd
ones already set up and maintained elsewhere. We already rely on the
bfd library, so leveraging the endian aspect should be fine.
The m32r port was using the device framework to handle two devices: the
cache and uart registers. Both can be implemented in the newer hardware
framework instead which allows us to drop the device logic entirely, as
well as delete the tconfig.h file.
While creating the new uart device model, I also added support for using
stdin to read/write data rather than only supporting sockets.
This has been lightly tested as there doesn't appear to be test coverage
for the code already. If anyone still cares about this port, then they
should (hopefully) file bug reports.
This partially reverts commits:
105dd264de3df3af7c3fc4892a6b379e3042ec07
Now that dv-sockser is handled entirely by the common build logic, the
failure these targets were hitting isn't really possible anymore. Lets
reset their hardware status back to defaulting to on. Some of these
were set to "always" previously, but we don't support that anymore.
The situation here is similar to that of the other nearby (previous)
sims fixed; it fails at the dv_sockser_install declaration in
sim/m32r/tconfig.in. But, as opposed to e.g. frv, this *does* have a
definition of UART_INCHAR_ADDR et al. It's somewhat tempting to keep
sim-hardware enabled here but, I'm disabling it for the same reasons
as for frv. Unsurprisingly (as m32r seems to be the template), the
same confusing lines are in sim/m32r/Makefile.in as in
sim/frv/Makefile.in at that time, deleted in 73e76d20. Again, commit
73e76d20 (for m32r as well as for frv) attempted to move the
non-existing dv-sockser.o use to $(m32r_extra_objs) but missed that
AC_SUBST would only affect @m32r_extra_objs@ and not
$(m32r_extra_objs) per se so nothing happened. As for frv, I'm
removing the $(m32r_extra_objs) too, to avoid confusion. Make
check-sim for m32r-elf shows no regressions (5 failures; 100 expected
passes) compared to bf3d9781ec (before the recent config.in regen,
after sim-hardware mostly-enabled) and eed23bb4a1 (before the
sim-hardware mostly-enabled; 2013-03-23).
sim/m32r:
* configure.ac: Default simulator hardware to off again. Remove
dead m32r_extra_objs substitution.
* configure: Regenerate.
* Makefile.in: Remove unused frv_extra_objs.
These sims have optional support for the dv-sockser model, so do not make
them hard failures. The Makefile made it seem like they didn't actually
support things dynamically, but a further code dive into the source and
the Makefile shows that things work out.
Automake likes to dump macros automatically used into the aclocal.m4
file, but the common/aclocal.m4 naming prevents that. So rename it
to the more normal "acinclude.m4" so the aclocal tool can work.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Now that the sourceware tree generally requires autoconf-2.64, update
the sim tree to require that too.
This allows us to drop the long standing SIM_AC_COMMON/common.m4
workaround as autoconf 2.64+ seems to work for me.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2005-01-12 Andrew Cagney <cagney@gnu.org>
* configure.ac: Update to use ../common/common.m4.
* configure: Re-generate.
Index: mn10300/ChangeLog
2005-01-12 Andrew Cagney <cagney@gnu.org>
* configure.ac: Update to use ../common/common.m4.
* configure: Re-generate.
Index: d10v/ChangeLog
2005-01-12 Andrew Cagney <cagney@gnu.org>
* configure.ac: Update to use ../common/common.m4.
* configure: Re-generate.
Index: erc32/ChangeLog
2005-01-12 Andrew Cagney <cagney@gnu.org>
* configure.ac: Update to use ../common/common.m4.
* configure: Re-generate.
Index: frv/ChangeLog
2005-01-12 Andrew Cagney <cagney@gnu.org>
* configure.ac: Update to use ../common/common.m4.
* configure: Re-generate.
Index: h8300/ChangeLog
2005-01-12 Andrew Cagney <cagney@gnu.org>
* configure.ac: Update to use ../common/common.m4.
* configure: Re-generate.
Index: m32r/ChangeLog
2005-01-12 Andrew Cagney <cagney@gnu.org>
* configure.ac: Update to use ../common/common.m4.
* configure: Re-generate.
Index: mcore/ChangeLog
2005-01-12 Andrew Cagney <cagney@gnu.org>
* configure.ac: Update to use ../common/common.m4.
* configure: Re-generate.
Index: mips/ChangeLog
2005-01-12 Andrew Cagney <cagney@gnu.org>
* configure.ac: Update to use ../common/common.m4.
* configure: Re-generate.
Index: v850/ChangeLog
2005-01-12 Andrew Cagney <cagney@gnu.org>
* configure.ac: Update to use ../common/common.m4.
* configure: Re-generate.
Index: common/ChangeLog
2005-01-12 Andrew Cagney <cagney@gnu.org>
* common.m4: New file, based on of aclocal.m4.
Index: arm/ChangeLog
2005-01-12 Andrew Cagney <cagney@gnu.org>
* configure.ac: Update to use ../common/common.m4.
* configure: Re-generate.
