The Blackfin port had some TRACE_xxx macros for easily logging trace data.
Use these as a base for common ones that have a simple form and match the
existing sets of helper macros.
The cgen code declares some macros/funcs using the trace_xxx prefix, but
the code isn't generic and only works with cgen targets. This is blocking
the creation of new common trace functions.
Let's blindly add cgen_xxx prefixes to all these symbols. Some already
use this convention to avoid conflicts, so it makes sense to align them.
In the future we might want to move some to the common trace core, but
one thing at a time.
First we convert the ETRACE_P to STRACE_EVENTS_P. This means we move from
using the sim_events.trace storage to the common sim_state_base.trace_data
array. With that deleted, the common trace init code can be simplified so
the sim state works the same as the sim cpu.
Now that libgloss has a header tracking the syscalls for this arch, we
can update the database to include it for the symbolic constants/maps.
Then we can switch the mcore syscall callbacks over to the common ones.
Since newlib no longer shares the same repo as binutils/gdb, we have to go
searching further afield to locate the sources. We still look at the top
level for newlib, but if that is not found, we also try up one dir outside
of this source tree. It sucks, but better than the status quo (no workie).
Since every target typedefs this the same way, move it to the common code.
We have to leave Blackfin behind here for now because of inter-dependencies
on types and headers: sim-base.h includes sim-model.h which needs types in
machs.h which needs types in bfim-sim.h which needs SIM_CPU.
Almost every target defines sim_cia the same way -- either using the
address_word type directly, or a type of equivalent size. The only
odd one out is sh64 (who has 32bit address_word and 64bit cia), and
even that case doesn't seem to make sense. We'll put off clean up
though of sh64 and at least set up a sensible default for everyone.
The CIA_{GET,SET} macros serve the same function as CPU_PC_{GET,SET}
except the latter adds a layer of indirection via the sim state. This
lets models set up different functions at runtime and doesn't reach so
directly into the arch-specific cpu state.
It also doesn't make sense to have two sets of macros that do exactly
the same thing, so lets standardize on the one that gets us more.
Now that all the targets are utilizing CPU_PC_{FETCH,STORE}, and the
cpu state is multicore, and the STATE_CPU defines match, we can move
it all to the common code.
The old run frontend had a --version option, but the new common
sim-options file does not. Restore support for that so we can
get version info out of `run` when using the new frontend.
Now that all targets have been converted to nrun, we can finally punt
this old inconsistent interface.
A few stray references to the old run were sprinkled about; clean them
up in the process.
We leave behind the run(1) man page mostly so that we get it updated for
the new nrun interface.
With newer versions of gcc (5.x), the extern inline we're using with the
cgen-{mem,ops} modules no longer work. Since this code really wants the
gnu inline semantics, use that attribute explicitly.
With newer versions of gcc (5.x), the extern inline we're using with the
sim-arange module no longer works. Since this code really wants the gnu
inline semantics, use that attribute explicitly.
Reported-by: DJ Delorie <dj@redhat.com>
Reported-by: Joel Sherrill <joel.sherrill@oarcorp.com>
The profile code was using STATE_WATCHPOINTS to get access to the PC, but
we already have a standard method for getting the pc, so switch to that.
This assumes that sizeof_pc is the same size as sim_cia, but we already
assume this in places by way of sim_pc_{get,set}, and this is how it's
documented in the sim-base.h API.
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>
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.
This dates back to the start of the repo, but has never really been used.
The sim-inline.c file has been checked in to the source, and attempts to
build it in the build tree leads to a circular dep warning from make. It
also doesn't produce a file that is usable -- it can't be compiled. Punt!
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.
Since sim-endian.c doesn't actually use sim_io funcs, it's weird to
include the sim-io.h header here. It's doing so only for the assert
header. So lets relocate the include to the right place.
... using automake 1.11.1, which is the version we're currently
using throughout, instead of 1.11.3. This should be a no-op in
practice, but will help automake/aclocal version-related
differences to cloud real changes being made.
sim/common/ChangeLog:
* aclocal.m4, configure: Regenerate using automake 1.11.1.
On Windows, a recent gnulib update imported the lstat module, and
this caused a remote-sim.c build failure in struct host_callback_struct:
In file included from /[...]/gdb/remote-sim.c:34:0:
/[...]/gdb/../include/gdb/callback.h:93:9: error: duplicate member '_stati64'
int (*lstat) (host_callback *, const char *, struct stat *);
^
What happens it that gnulib's stat.h makes the following defines:
/* Large File Support on native Windows. */
#if 1
# define stat _stati64
#endif
and then:
#if 1
# if ! 0
/* mingw does not support symlinks, therefore it does not have lstat. But
without links, stat does just fine. */
# if !(defined __cplusplus && defined GNULIB_NAMESPACE)
# define lstat stat
# endif
So, the following fields in struct host_callback_struct...
int (*stat) (host_callback *, const char *, struct stat *);
int (*fstat) (host_callback *, int, struct stat *);
int (*lstat) (host_callback *, const char *, struct stat *);
... get translated to...
int (*_stati64) (host_callback *, const char *, struct _stati64 *);
int (*_fstati64) (host_callback *, int, struct _stati64 *);
int (*_stati64) (host_callback *, const char *, struct _stati64 *);
... which causes two fields to have the same name.
This patch fixes the issue by renaming the stat-related fields
by adding a "to_" prefix, similar to what is done in GDB's
target_ops vector.
include/gdb/ChangeLog:
* callback.h (struct host_callback_struct) <to_stat>: Renamed
from "stat".
<to_fstat>: Renamed from "fstat".
<to_lstat>: Renamed from "lstat".
sim/common/ChangeLog:
* sim-io.c (sim_io_stat, sim_io_fstat): Adjust calls to "stat"
and "fstat" callbacks by calls to "to_stat" and "to_fstat" (resp)
callbacks following renaming in callback.h.
* syscall.c (cb_syscall): Likewise. Adjust calls to "lstat"
callback by call to "to_lstat" callback
sim/cris/ChangeLog:
* traps.c (cris_break_13_handler): Adjust call to "fstat" callback
by call to "to_fstat" following renaming in callback.h.
sim/h8300/ChangeLog:
* compile.c (sim_resume): Adjust calls to "stat" and "fstat"
callbacks by calls to "to_stat" and "to_fstat" (resp) callbacks
following renaming in callback.h.
GDB and SIM both have functions called "debug_printf", which conflicts
at link time. This commit shadows SIM's debug_printf with a macro so
that SIM's symbol ends up being called "sim_debug_printf".
sim/common/ChangeLog:
* sim-trace.h (debug_printf): New define.
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.
It is rare for people to want to modify the cmd arg. In general, they
really shouldn't be, but a few still do. For those who misbehave, dupe
the string locally so they can bang on it.