The current default handling for the --enable-sim-hardware option ends up
forcing the value to whatever is set as the first argument when calling
the macro (by virtue of how autoconf works). Relocate the setup code to
the 4th parameter of the AC_ARG_ENABLE macro to fix it.
This was caused by the simplification work in 1517bd2742.
Reported-by: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
Since no sim is using the "always" option to SIM_AC_OPTION_HARDWARE, and
we don't want to require hw support to always be enabled, drop the option.
This leads to a slight simplification in the macro too as we can collapse
the sim_hw_p variable.
If dv-sockser is available, lets add it to the common SIM_HW_OBJS
variable so it is always included automatically. Now ports do not
have to shoe horn it in directly themselves. It does mean it will
be compiled for targets that don't explicitly use it, but that's
really what we want anyways.
This lets ports assume that the dv-sockser API is always available if
they want to. This way we don't have to do an abort at configure time
and it makes the resulting code a bit simpler.
Rather than manually include tconfig.h when we think we'll need it (which
is error prone as it can define symbols we expect from config.h), have it
be included directly by config.h. Since we know we have to include that
header everywhere already, this will make sure tconfig.h isn't missed.
It should also be fine as tconfig.h is supposed to be simple and only set
up a few core defines for the target.
This allows us to stop symlinking it in place all the time and just use
it straight out of the respective source directory.
Pull out the duplicated dv_sockser_install prototype from the tconfig.in
files and put it in the one place it gets used -- sim-module.c. This is
still arguably incorrect, but it's better than the status quo where the
tconfig.in has to include header files and duplicate the dv-sockser func.
The tconfig header is meant to be simple and contain a target defines.
We want people to stop using the run.c frontend, but it's hard to notice
when it's still set as the default. Lets flip things so nrun.c is the
default, and users of run.c will get an error by default. We turn that
error into a warning for existing sims so we don't break them -- this is
mostly meant for people starting new ports.
Add a trailing semi-colon to the sed print command as the BSD sed
implementation wants it. It's a nop otherwise and works fine on
GNU/etc... implementations too.
The use of $< ends up picking the wrong object out of the depend
list. Specify the input name directly to avoid fragility.
On BSD systems, we need to make sure all options come before the
non-options (i.e. the files).
Reported-by: Chris Johns <chrisj@rtems.org>
URL: https://sourceware.org/bugzilla/show_bug.cgi?id=13160
Directories that don't use libtool need to add -ldl (on most *nix
hosts) to provide dlopen for libbfd.
config/
* plugins.m4 (AC_PLUGINS): If plugins are enabled, add -ldl to
LIBS via AC_SEARCH_LIBS.
gdb/
* acinclude.m4 (GDB_AC_CHECK_BFD): Don't add -ldl.
* config.in: Regenerate.
sim/ppc/
* configure.ac: Invoke AC_PLUGINS.
* config.in: Regenerate.
and regen lots of configure files.
This removes the last uses of PARAMS from sim.
2014-01-06 Tom Tromey <tromey@redhat.com>
* README-HACKING: Don't use PARAMS.
* arm/wrapper.c: Don't use PARAMS.
* bfin/sim-main.h: Don't use PARAMS.
* common/callback.c: Don't use PARAMS.
* common/cgen-trace.c: Don't use PARAMS.
* common/run-sim.h: Don't use PARAMS.
* common/run.c: Don't use PARAMS.
* common/sim-base.h: Don't use PARAMS.
* common/sim-load.c: Don't use PARAMS.
* common/sim-options.h: Don't use PARAMS.
* common/sim-trace.c: Don't use PARAMS.
* common/sim-trace.h: Don't use PARAMS.
* common/sim-utils.h: Don't use PARAMS.
* cr16/cr16_sim.h: Don't use PARAMS.
* cr16/gencode.c: Don't use PARAMS.
* cr16/interp.c: Don't use PARAMS.
* cr16/simops.c: Don't use PARAMS.
* d10v/d10v_sim.h: Don't use PARAMS.
* d10v/gencode.c: Don't use PARAMS.
* d10v/interp.c: Don't use PARAMS.
* d10v/simops.c: Don't use PARAMS.
* erc32/erc32.c: Don't use PARAMS.
* erc32/exec.c: Don't use PARAMS.
* erc32/float.c: Don't use PARAMS.
* erc32/func.c: Don't use PARAMS.
* erc32/sis.c: Don't use PARAMS.
* erc32/sis.h: Don't use PARAMS.
* mips/interp.c: Don't use PARAMS.
* mips/sim-main.h: Don't use PARAMS.
* sh/interp.c: Don't use PARAMS.
* v850/sim-main.h: Don't use PARAMS.
* v850/v850_sim.h: Don't use PARAMS.
The SEARCH insn is an oddball when it comes to parallel usage. It places a
big limit on what other insns it can run in parallel with, but we don't
currently track the amount of state needed to verify this (since no other insn
really requires this). Add a note for now in case we get around to it.
For many of the 32bit dsp shift related insns, we were just ignoring the HLs
field. The hardware does not though and will reject the insn if it's set
incorrectly. Update the sim to match.
We wrote a test case that tries every single 32bit opcode on the hardware
and compared it to the sim. There were a bunch of places in the sim where
we weren't strict enough (requiring certain parts of the opcode be set) so
we were treating a lot of invalid opcodes as valid ones. This sprinkles
out a lot additional checks in the dsp32alu class.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Since many people don't have a Blackfin toolchain available, only try to
regenerate the header file when in maintainer mode. This file rarely changes,
and when it does, we commit the generated output, so there's almost never a
need to run directly on an end system.
I noticed the sim code is using an old implementation of the maintainer logic.
I cut it over to the new macro (like gdb has been doing). In practice, it
makes no difference currently as nothing in the sim tree uses it, but I have a
follow up commit for the Blackfin tree that needs it.
There's no need to put the majority of the logic into the 3rd arg of the
AC_ARG_ENABLE. Coupled with the lack of indentation, it makes it hard to
follow, error prone to update, and duplicates code (with the 4th arg).
So pull the logic out of the 3rd arg and outside of the AC_ARG_ENABLE
macro. This allows us to gut the 4th arg entirely, merge with the code
that followed the macro, and fix bugs related to the new dv-sockser in
the process.
Hopefully building the various sims with the default sim-hardware
settings, as well as with explicit --{dis,en}able-sim-hardware flags,
should all just work now.
Two modifications:
1. The addition of 2013 to the copyright year range for every file;
2. The use of a single year range, instead of potentially multiple
year ranges, as approved by the FSF.
When the sim is built w/out the bfroms, we end up passing a length of 0 when
mapping the rom region which the core sim code rejects. So add an alias field
equal to the length to avoid that error.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The latest gdb sim-remote.c really wants a return value from the fetch/store
register functions, so update the Blackfin sim to avoid the warnings/errors.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Newer BF54x parts feature an updated GPIO block where all the interrupt
handling is split off, so create a new model for the pin interrupts.
This is missing the port forwarding aspects, but at least the register
interface should be there.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
More ASTAT directed fixes, but this time at the dsp32shift insns.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This improves some of the arithmetic shifts to better match the
hardware (especially wrt ASTAT behavior). We hit areas where
the published documentation is thin so we have to rely on tests
run on the hardware to figure out how things should behave.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Now that we keep track of the exact parallel insn slot we're in, we can
make sure that the current insn being decoded is valid for that slot.
This brings us much closer to the hardware in flagging invalid parallel
insn combinations.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Some insns need to know which slot they're in to determine whether they
are valid. So add an enum for each slot, and check that rather than the
overall insn len. This makes tracking things in the code much clearer.
However, this code is functionally the same, so a follow up patch will
leverage this more to properly flag invalid parallel insn combos.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The amod1 helper includes a leading space so it can expand into the empty
string when need be, which means the caller need not add spacing itself.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Parallel insns can only do one 32bit, then two 16bits. So if we see
a 2nd 32bit insn after the first 32bit in a parallel insn, abort.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This fix the build time warning:
warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
machs.c: In function 'bfin_model_cpu_init':
machs.c:1657:1: warning: 'bfrom' may be used uninitialized
in this function [-Wuninitialized]
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Fix warning about mixing decls and code by moving auxvt_size decl
down to the scope where it is used.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The current code triggers a warning:
dv-bfin_sic.c: In function 'bfin_sic_finish':
dv-bfin_sic.c:930:41: warning: operation on 'sic-><U78e8>.bf54x.iwr1'
may be undefined [-Wsequence-point]
This points out the IWR2 register was not being setup because of a typo.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The place where these funcs get defined do not include the header that
declares their prototypes. Add that to fix -Wmissing-prototypes:
devices.c:59:1: warning: no previous prototype for 'dv_bfin_mmr_invalid'
devices.c:66:1: warning: no previous prototype for 'dv_bfin_mmr_require'
devices.c:99:1: warning: no previous prototype for 'dv_bfin_mmr_check'
devices.c:159:14: warning: no previous prototype for 'dv_get_bus_num'
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
