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>
The local save_data() function takes a pointer to a buffer and only uses it as
the source to the memcpy() function. Since it is given const strings, GCC
likes to spit out warnings:
common/sim-trace.c: In function 'trace_prefix':
common/sim-trace.c:697: warning: passing argument 5 of 'save_data' discards
qualifiers from pointer target type
So I've committed this as obvious.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The sim-options code assigns a const string to "char *" in decoding the
current environment settings, and only uses it to pass to a printf. GCC
outputs the warnings:
common/sim-options.c: In function 'standard_option_handler':
common/sim-options.c:271: warning: assignment discards qualifiers from pointer
target type
common/sim-options.c:272: warning: assignment discards qualifiers from pointer
target type
common/sim-options.c:273: warning: assignment discards qualifiers from pointer
target type
So I've committed this as "obvious".
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The accept() function takes a socklen_t, not an int. Using an int causes:
dv-sockser.c: In function 'connected_p':
dv-sockser.c:273: warning: pointer targets in passing argument 3
of 'accept' differ in signedness
So use the same socklen_t detection code as gdb and convert the accept().
This is the normal "passing a buffer straight to printf makes GCC warn".
While we know this particular case is fine, the trend in this source tree
is to fix this anyways to avoid the warnings.
GCC issues warnings because const strings like "foo" are passed as char*.
sim-watch.c: In function 'watchpoint_type_to_str':
sim-watch.c:120: warning: return discards qualifiers from pointer target type
