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.
This reverts part of the earlier version.in change. It moves
version.in back to the gdb directory. This works around the CVS bug
we've found.
gdb
* Makefile.in (version.c): Use version.in, not
common/version.in.
* common/create-version.sh: Likewise.
* common/version.in: Move...
* version.in: ...here.
gdb/doc
* Makefile.in (version.subst): Use version.in, not
common/version.in.
* gdbint.texinfo (Versions and Branches, Releasing GDB):
Likewise.
gdb/gdbserver
* Makefile.in (version.c): Use version.in, not
common/version.in.
sim/common
* Make-common.in (version.c): Use version.in, not
common/version.in.
* create-version.sh: Likewise.
sim/ppc:
* Make-common.in (version.c): Use version.in, not
common/version.in.
This change is required now that gdb/version.in has been moved to
gdb/common/version.in and now that the date needs to be fetched
from bfd/version.h.
sim/common/ChangeLog:
* create-version.sh: New script. Adapted from
gdb/commong/create-version.sh.
* Make-common.in (version.c): Update rule dependencies,
and re-implement using create-version.sh.
sim/ppc/ChangeLog:
* Makefile.in (srccom): New variable.
(version.c): Update rule dependencies, and re-implement using
sim/common/create-version.sh.
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.
* acinclude.m4: Add SIM_DV_SOCKSER_O which is empty on hosts
which do not support dv-sockser.o. Add always as option to
first argument to SIM_AC_OPTION_HARDWARE. Fail if hardware
is always required to be enabled by simulator.
* wrapper.c: Include config.h before system header files.
* callback.c: Include config.h before system header files.
* cgen-trace.c: Likewise.
* cgen-utils.c: Likewise.
* gentmap.c: Likewise.
* sim-if.c: Include config.h before system header files.
* compile.c: Include config.h before system header files.
* sim-main.h: Likewise.
* gdb-if.c: Include config.h before system header files.
* load.c: Likewise.
* syscalls.c: Likewise.
* trace.c: Likewise.
* interp.c: Include config.h before system header files.
The common code has a sim_core_trans_addr() helper that only the m32r code
uses. Move the inline extern in the m32r code to the proper common header.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Before POSIX standardized strsignal(), old systems would hide the
prototype unless the normal extension defines were enabled. So use
the AC_USE_SYSTEM_EXTENSIONS helper for that.
Then make sure we include string.h ourselves in nrun.c rather than
relying on implicit includes via other sim headers.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The sim code gets the logic for SIM_AC_OPTION_WARNINGS from gdb, but
it hasn't been updated in a good long while. Sync with the latest
gdb code.
There is a sim specific change in here: we disable -Werror for now.
This is because all sim code atm contains warnings. Will probably
have to slowly add a white list of targets which can tolerate this
until everyone is updated.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This isn't entirely correct in that it assumes the signal numbering of
the target and host match, but seeing as we already make that assumption
in a few places, this patch doesn't make the situation any worse.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Trying to run `headers` in an out-of-tree build fails atm due to the
relative srcdir paths being used in a location other than where they
were setup to be used from. Get abs_srcdir from configure and use
that instead where applicable.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Building the sim on a sparc-solaris 2.8 machine fails when configured
with no extra sim hardware:
> for hw in ; do \
> echo "extern const struct hw_descriptor
> dv_${hw}_descriptor[];" ; \
> done >> tmp-hw.h
> echo 'const char version[] = "'"`sed q
> /[...]/../../gdb/version.in`"'";'
> >> version.c-tmp
> /bin/sh: -c: line 1: syntax error near unexpected token `;'
> /bin/sh: -c: line 1: `for hw in ; do \'
> make[3]: *** [hw-config.h] Error 2
The same thing happens with the version of bash that we got from
Sun as well (which is very old: 2.03.0(1)-release).
The problems comes from the fact that both shells are buggy, and
reject the following script:
for hw in ; do
[...]
done
The above is what sim/common/Makefile.in tries to execute when
generating hw-config.h.
In order to allow users to build out of the box on these machines,
this patch works around this bug. It does rely on the fact that
none of the tokens in SIM_HW contain whitespaces.
sim/common/ChangeLog:
* Make-common.in (hw-config.h): Work around bug in Solaris 2.8
system bourne shell.
The common sim code provides a useful "get_string" function which reads
a C string out of the target's memory space. So rename and export it
for other people to use.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Lift the code that GDB is using to generate dependencies on the fly and
port it over to the sim. Now people shouldn't have to manually maintain
these in their Makefile's.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Some systems (like OS X) do not have posix_fallocate. Add a configure
check for it before we try to use it. This is less work than trying
to support old systems.
URL: http://sourceware.org/bugzilla/show_bug.cgi?id=13161
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
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>
The dv-cfi code uses the bool type but doesn't include the stdbool.h
header. I didn't notice for Blackfin targets as the core Blackfin
header will include stdbool.h, but most targets don't do this.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The "devices.h" header is Blackfin-specific, so trying to build dv-cfi
for any other target fails. Include the specific hw headers this file
needs directly.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Seems some fixes were added to the common.m4 file but not the
SIM_AC_COMMON macro. Keep the two in sync since they're supposed
to be the same thing.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The sim_args_command prototype is in sim-options.h, so pull it in
directly rather than assuming a common header does it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Shell code before AC_INIT will be silently culled, and since the common
aclocal.m4 includes inline shell code, the file cannot be included before
AC_INIT. So update the example to show people including the file after
that rather than before to avoid random breakage.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The autoconf guys point out that our usage of AC_PROG_CC in the
SIM_AC_COMMON does not jive with their intended use.
http://www.gnu.org/software/autoconf/manual/autoconf.html#Expanded-Before-Required
So utilize AC_REQUIRE to make the warnings go away and generate
the correct code with different autoconf versions.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Since sim_do_command for many people simply calls sim_args_command, start
a unified version of it. For people who handle their own options, they
could switch to this by using sim_add_option_table instead.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The current --sysroot parsing attempts to keep from leaking memory by
treating the empty string specially (sine this is the initial value),
but it ends up leaking memory when the arg is an empty string. So if
someone uses --sysroot "", the old value is leaked, as is the new one.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
A semi-recent change which regenerated nltvals.def somehow missed all of
the Blackfin syscalls. So regenerate against the latest tree to get them
back.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
It's useful to be able to trace just the system calls the simulated
program is calling, so add a new --trace-syscall option for ports to
leverage if they choose.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Some Blackfin parts tie a bunch of interrupt lines into a single OR
gate before feeding the result into the SIC. The glue-or device in
the sim provides a nice way of modeling this exact behavior. At the
moment though, it requires the device to be mapped into the address
space so that things could write to it directly. This is not needed
for the Blackfin usage, so make it optional. Now the glue devices
can be used to simply tie interrupt lines together.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The glue device has a bunch of "todos" for the misc bitwise devices.
So implement two for fun -- the glue-or and glue-xor.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
For now, only the sub-command name is completed. No support yet for
completing options to that command. But even this is a huge step as
currently, nothing is completed, and the basic "help sim" is fairly
obtuse as to what exactly the "sim" command accepts.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This simulates a CFI flash. Its pretty configurable via the device
tree. For now, only basic read/write/erase operations are supported
for the Intel command set, but it's easy enough to extend support.
It's certainly enough to trick Das U-Boot into using it for probing,
reading, writing, and erasing.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This can boot Das U-Boot and a Linux kernel. It also supports Linux
userspace FLAT and FDPIC (dynamic and static) ELFs.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The sim keeps track of which allocations are zero-ed internally (via
zalloc) and then calls a helper "zfree" function rather than "free".
But this "zfree" function simply calls "free" itself. Since I can
see no point in this and it is simply useless overhead, punt it.
The only real change is in hw-alloc.c where we remove the zalloc_p
tracking, and sim-utils.c where zfree is delete. The rest of the
changes are a simple `sed` from "zfree" to "free".
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The sim-events code jumps through some hoops to avoid using 64bit math
to manage the current time. One fundamental assumption here is that by
constantly scheduling the sim poll event a short time into the future,
the 64bit difference will always fall into a signed 32bit value. This
does work most of the time, except for when processing the sim poll event
itself.
Normally, sim_events_process() will dequeue the sim poll event, update
the current time (time_from_event) according to the next pending event,
process the sim poll event (which will then requeue the sim poll event),
and then continue on.
The problem here of course is that the current time is updated in that
small window before the sim poll event gets a chance to reschedule itself.
So if the 64bit difference between the current time and the next event
does not fit into the signed 32bit value, time_from_event overflows, and
the internal assert at the end of update_time_from_event() triggers.
Since attempts at tweaking sim_events_process() logic introduced other
subtle bugs (due to tangled assumptions between most pieces of the sim
time keeping code), change the time_from_event to a real 64bit value.
Tests on my system between a 32bit ELF and a 64bit ELF show no practical
difference (it's all lost in the system noise). Basically, I booted a
Linux kernel to userspace and then paniced it; this gave me a constant
sample size of about 18 million insns.
This was noticed when simulating Blackfin Das U-Boot. The simulated core
timer is given the max unsigned timeout value possible on a 32bit processor
(0xffffffff). This timeout value is used directly to schedule a hw event
in the sim future (the IRQ firing). Once the sim poll event is kicked off,
the next pending event is the core timer event which is more than 2^31
ticks in the future, and the sim aborts with:
sim-events.c:435: assertion failed - current_time == sim_events_time (sd)
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
I can't find any history for why the call to hw_tree_delete is commented
out, and the VCS history shows that this goes back to the original import
in 2009. I did find some vague reference to it from 2000 (pretty close
to the original import of code), but no actual details.
Without this call, every new instance of the sim results in all old
previously allocated resources being leaked. With some devices, this
isn't just memory, it's things like open file descriptors or mmaps.
So if there are pending issues with this, I'd rather we get the sims
sorted out rather than continuing to leak this stuff. Especially since
the "let's wait for the sims to fix themselves" hasn't actually happened
in the last 10+ years.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
I find it annoying when using --memory-mapfile that I also need to look
up and manually specify the file size to the following --memory-region
option. So make a length of 0 in the following --memory-region trigger
an auto-sizing of the map to the length of the file being mapped.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The 2nd arg to SIM_AC_OPTION_HARDWARE is described as "a space separated
list of devices that override the defaults" while the 3rd arg is "a space
separated list of extra target specific devices". But the macro doesn't
seem to treat the 2nd arg this way.
Instead, it will always add the default list of devices, and only add the
extra target specific devices if the 2nd arg is not specified. So rework
the logic slightly to handle the 2nd arg as documented.
This shouldn't affect any targets in the tree as no one passes in a non-
empty value as the 2nd arg.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
These functions either call abort() themselves, or call functions which
are already marked noreturn. Either way, they don't return, so mark them
as such so calling code can assume this. This fixes some uninitialized
warnings due to code paths that end in an abort function.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The sim_load_file func creates a buffer with arbitrary data in it (reads
it via the bfd). It then passes it on to a sim_write_fn which expects a
unsigned char buffer. Since sim_load_file itself doesn't care about the
contents, tweak the type to avoid signed mismatch warnings from gcc:
common/sim-load.c: In function ‘sim_load_file’:
common/sim-load.c:143: warning: pointer targets in passing argument 3 of ‘do_write’ differ in signedness
common/sim-load.c:143: note: expected ‘const unsigned char *’ but argument is of type ‘char *’
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
We have malloc (uninitialized buffer), zalloc (zeroed buffer), and
nzalloc (zeroed array). But we don't have a way to allocate an
uninitialized array. Add a HW_NALLOC to fill this gap.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The HW_NZALLOC macro has all caps args for some reason (unlike the other
alloc helpers), and ends up not using the "ME" argument since its copy
and paste source uses "me". Make all the args lowercase to match the
style of all the other args and make it use the correct "me".
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
There are options for listing the current device/hw tree and memory
regions, but no way to find out at run time all the current mappings.
So add a new --map-info option akin to the --memory-info option which
displays all the current mappings.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When the sim is configured with profile support disabled, the build fails:
./../common/sim-profile.c: In function 'profile_option_handler':
./../common/sim-profile.c:337:6: warning: implicit declaration of function 'PROFILE_PC_FREQ'
./../common/sim-profile.c:337:6: error: lvalue required as left operand of assignment
./../common/sim-profile.c:351:6: warning: implicit declaration of function 'PROFILE_PC_NR_BUCKETS'
./../common/sim-profile.c:351:6: error: lvalue required as left operand of assignment
./../common/sim-profile.c:381:6: warning: implicit declaration of function 'PROFILE_PC_SHIFT'
./../common/sim-profile.c:381:6: error: lvalue required as left operand of assignment
./../common/sim-profile.c:405:8: warning: implicit declaration of function 'PROFILE_PC_START'
./../common/sim-profile.c:405:8: error: lvalue required as left operand of assignment
./../common/sim-profile.c:406:8: warning: implicit declaration of function 'PROFILE_PC_END'
./../common/sim-profile.c:406:8: error: lvalue required as left operand of assignment
./../common/sim-profile.c: In function 'profile_uninstall':
./../common/sim-profile.c:1299:7: warning: implicit declaration of function 'PROFILE_INSN_COUNT'
./../common/sim-profile.c:1299:37: warning: comparison between pointer and integer
./../common/sim-profile.c:1300:2: warning: passing argument 1 of 'zfree' makes pointer from integer without a cast
../common/sim-utils.h:30:6: note: expected 'void *' but argument is of type 'int'
make[2]: *** [sim-profile.o] Error 1
So add some stubs similar to how some of the other subsystems are
stubbed out so things build correctly.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When building with device and hw support, the sim-core code generates a
lot of build time warnings such as:
./../common/sim-core.c: In function 'sim_core_map_attach':
./../common/sim-core.c:198:7: warning: passing argument 1 of 'device_error' from incompatible pointer type
../common/sim-core.h:347:6: note: expected 'struct device *' but argument is of type 'struct hw *'
./../common/sim-core.c:235:7: warning: passing argument 1 of 'device_error' from incompatible pointer type
../common/sim-core.h:347:6: note: expected 'struct device *' but argument is of type 'struct hw *'
In reality, these two structures get cast back and forth in the core
code already and so are "compatible". So tweak the three functions
that generate all of these warnings to include the casts automatically.
I know this isn't exactly clean, but the current device/hw ifdef
approach is full of landmines itself and I'm not entirely sure how
to unscrew it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Rather than having to bang out chunks of data one byte at a time over
the socket interface, add a write variant that accepts an arbitrarily
long buffer. This speeds things up considerably when we have many
chars to send out at once.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
gdb/
* ser-tcp.c (net_open): Check error return from socket() call by its
equality to -1 not by it being negative.
(net_close): Likewise.
gdb/gdbserver/
* gdbreplay.c (remote_open): Check error return from socket() call by
its equality to -1 not by it being negative.
* remote-utils.c (remote_open): Likewise.
sim/arm/
* communicate.c (MYread_char): Check error return from accept() call
by its equality to -1 not by it being negative.
(MYread_charwait): Likewise.
* main.c (main): Likewise for both socket() and accept() calls.
sim/common/
* dv-sockser.c (dv_sockser_init): Check error return from socket()
call by its equality to -1 not by it being negative.
(connected_p): Likewise for accept() call.
sim/cris/
* dv-rv.c (hw_rv_init_socket): Check error return from socket() call
by its equality to -1 not by it being negative.
(hw_rv_write): Likewise.
(hw_rv_handle_incoming): Likewise.
(hw_rv_poll_once): Likewise.
* rvdummy.c (setupsocket): Likewise.
(main): Likewise for accept() call as returned from setupsocket().
sim/m32c/
* main.c (setup_tcp_console): Check error return from socket() call
by its equality to -1 not by it being negative.
The current fpu code with externals enabled results in the warnings:
common/sim-fpu.c:2437: warning: missing initializer
common/sim-fpu.c:2437: warning: (near initialization for 'sim_fpu_zero.sign')
common/sim-fpu.c:2440: warning: missing initializer
common/sim-fpu.c:2440: warning: (near initialization for 'sim_fpu_qnan.sign')
So tweak the old style initializers to avoid these.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The common/ code uses sim_cpu rather than SIM_CPU to avoid inter-header
dependency issues, so follow convention to fix building some targets.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The profile code already has options and handling for accepting a file to
write the profile output like the trace code, but it doesn't actually use
it. At the moment, it simply opens the file at the start and closes it at
the end. So add two new local functions the way the trace code is doing
it and have them figure out whether to write the output to stdout or the
specified file. Then convert all existing output in the profile code to
use these helpers.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
There is an architecture-info flag for listing possible arch values, but
there is on equivalent for listing possible model values. So add the
equivalent for models.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
A few ports rely on internal dv-sockser state in order to detect whether
a connection has been made (look for 'extern sockser_addr'). Rather than
continuing that tradition, extend the existing status function to return
the socket connection status.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Most the sim write functions declare their source buffer const because
they only ever read from it. The global sim_write() function does not
follow this convention though which causes some warnings when trying to
pass it const strings or buffers.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The profile code has a lot of helper macros already, but none yet for the
branch profiling code. So add ones for the basic functions -- taken and
untaken branches.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The sim code has a lot of static initializer for options and devices, but
since they aren't using newer struct style, they have to specify a value
for every option otherwise gcc spits a lot of warnings about "missing
initializer". So add NULL/0 stubs for pointers/values.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The dup_arg_p function is only given const strings, and it maintains a
local table of those const strings. So constify the whole thing to fix
the GCC warnings:
common/sim-options.c: In function 'sim_parse_args':
common/sim-options.c:559: warning: passing argument 1 of 'dup_arg_p'
discards qualifiers from pointer target type
common/sim-options.c: In function 'print_help':
common/sim-options.c:675: warning: passing argument 1 of 'dup_arg_p'
discards qualifiers from pointer target type
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
I've committed the following patch as obvious. The local "prefix"
variable is only assigned const strings, and only passed to printf()
functions, so add "const" to avoid gcc warnings:
common/sim-fpu.c: In function 'sim_fpu_print_status':
common/sim-fpu.c:2508: warning: initialization discards qualifiers
from pointer target type
common/sim-fpu.c:2566: warning: assignment discards qualifiers
from pointer target type
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
