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 VIT_MAX insns can be used in parallel, so we need to use the store
buffer so we don't clobber the output register before we get a chance
to do a memory store with it.
Reported-by: Kai Iskratsch <kai@stella.at>
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>
The sim dir has 30 configure.ac files and 2 configure.in files.
So rename the minority to be consistent.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
* gen.c (insn_field_cmp): Tweak comment about neither field
being an insn_field_string with a cond_eq-to-value condition.
(insns_bit_useless) <case insn_field_string, case
decode_find_mixed>: Handle cond_eq-to-value fields as
insn_field_int.
* gen-idecode.c (print_idecode_validate): Handle
insn_field_string cond-equal-to-value fields as insn_field_int.
* gen-icache.c (print_icache_body): Add comment why constant
string fields are handled.
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 stat syscalls cannot work without a stat map, so declare one that
matches libgloss for virtual environments.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
* iwmmxt.c (WCMPGT): Sign extend 32-bit values before performing a
signed compare.
(WMAC): Extend computed result before adding to result register.
(WRSA): Sign extend 32-bit values before shifting.
Now that the Blackfin libgloss code extracts the 2nd result and the
error code from the R1/R2 registers, have the sim fill them up.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The LSHIFT/ASHIFT insns that work with accumulators lacked AV/AVS
handling in the ASTAT register, so add it to match the hardware.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
If we're shifting accumulators, we don't want to touch the V bit in
ASTAT, so add size checks to the ashiftrt/lshiftrt helpers.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The logical shift insn does not sign extend before shifting, so
we shouldn't either.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This too should have been squashed into an earlier change. It covers
a few more cases in the V/VS saturation patch when working with TFU
and FU modes of dsp insns.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When the shift magnitude exceeds 32 bits, the values rotate around (since
the hardware is actually a barrel shifter). So handle this edge case,
update the corresponding AV bit in ASTAT which was missing previously,
and tweak the AZ setting based on how the hardware behaves.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The shift magnitude is a 5-bit signed value. When it is between 0 and
15, then we do the requested shift, but when it is outside of that, we
have to do the opposite.
That means we flip between lshift and ashiftrt to match the hardware.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This reverts the previous commit and does it right. This change got
lost in the shuffle of patches I have pending.
Basically the logic is to change the 32bit saturation (and then masked
to 16bits) to a proper 16bit saturation.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Some saturation cases with dsp mac insns were not setting the V flag.
So implement that part and split up the logic between the dual macs.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Our handling of the M_IU/M_TFU modes are missing signed saturation when
the MM flag is set, so add it to match the hardware behavior.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
After testing the hardware with all the different dsp flags, the MM flag
triggers sign extension in all modes. So drop the limited use of it, and
the local custom helper that was also extending unsigned values. We also
can see that the flag checks in the mult/mac insns have the same behavior
with sign extending, so add a helper func to keep the logic the same in
both places.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When using the IH modifier, we need to first saturate the value before
rounding it, and then further saturate it a bit more. This makes the
sim match the hardware behavior with these insns.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When the accumulator saturates, it needs to be greater than, but not
equal to, the largest unsigned value as this is what the hardware does.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Fixes an error reported by Tristan and which can be evidenced by
doing:
% powerpc-elf-gdb
(gdb) target sim --sysroot=var
Invalid option: --sysroot=/var
[...]
sim/ppc/ChangeLog:
* psim.c (psim_options): Fix length of comparison when checking
for --sysroot= option.
This patch improves the error message when an invalid option is
detected, by also printing the option that actually caused the error.
For instance, from GDB:
(gdb) target sim --hello
Invalid option: --hello
Usage:
[...]
We also added the usage after an invalid long-name option (Eg: --hello)
to be in line with what's being done for all other invalid options
being detected.
sim/ppc/ChangeLog:
* psim.c (psim_options): Add option that cause the error
in invalid-option error messages. Print the usage when
detecting an invalid long-name option.
There was a recent change that cuased the "target sim" command
to add a --sysroot option to the argument vector passed down to
the simulator. This caused a failure in the powerpc simulator,
as it did not recognize it. This patch fixes the problem by adding
support for the --sysroot option (it ignores it).
sim/ppc/ChangeLog:
* psim.c (psim_options): Accept and ignore `--sysroot=...'.
Now that the common sim testsuite code supports .S and .c files, we
can import the Blackfin testsuite. There are about ~800 tests here,
so I'm only attaching a compressed patch of them. Other than adding
files to sim/testsuite/sim/bfin/, the sim/configure.tgt file was
updated to mark Blackfin as having a testsuite, and sim/configure
regenerated.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The BF537 family glues a bunch of peripherals into single interrupt lines
that run into the SIC. To model this same behavior in the sim, we need to
use the glue-or device, and in order to use that, we need to tweak things
a bit in the mach code to allow declaring of these new devices.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The machs.c file is the best place for holding cpu-specific details, so
restructure the way the SIC manages its ports to do just that. Now the
SIC's have a standard set of input pins and the different line routing
from peripherals is kept in the device tree only. This better models
the hardware where the SIC doesn't care about the exact peripheral that
is sending it stuff, just which input pin it gets it on.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This patch fixes a build failure at link time due to
sim_complete_command being undefined. There was a recent change
that added this function to all the ports that do not use the
common/ subdir. But somehow, the erc32 port got missed.
sim/erc32/ChangeLog:
* interf.c (sim_complete_command): New stub function.
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>
Now that the common code supports the syscall trace level, change the
Blackfin code from using the event level to the syscall level.
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>
Pull the model data (register addresses/sizes) out of the different model
files and into the machs.h header. The models themselves don't care about
where they're mapped, only the mach code does. This allows us to keep the
model headers from being included in the mach code which can cause issues
with model-specific names colliding. Such as when a newer device model is
created, but with incompatible register names/layouts.
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>
Rather than requiring all sim tests to be preprocessed .s files, add
support for .S and .c files so we can easily write code using a higher
level language like C.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The UART has a LOOP_ENA bit in its MCR register where writes to the THR
go to the RBR. Implement support for this mode.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
A few bits in the newer UART LSR register are not sticky, so make sure
we clear them when returning updated status rather than leaving them
always set.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Make all of the pins bidirectional, and support sending signals when
software drives the pins as outputs.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When the mask a/b MMRs are written, the output signal might change levels
(as pins are [un]masked), so make sure we update the output level.
Further, make sure we handle edge ints correctly by first sending a high
signal followed by a low signal.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
For the ports that don't use the common/ subdir, we need to add stub funcs
to them to avoid build failures with gdb and command completion. These do
not implement the actual completion functionality ... any port that wants
that can either convert to the common/ subdir, or fill out the function on
their own time.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
A bunch of 32bit insns were not using the store buffer, so when they were
used in parallel insns, they would incorrectly clobber a register early.
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>
When most video related insns are used in parallel with Ireg loads, the
DISALGNEXCPT insn behavior is implicitly in effect.
Reported-by: Anton Shokurov <shokurov.anton.v@yandex.ru>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The SIC latches ints from peripherals to the CEC, but the peripherals
need to be able to tell the SIC when to stop. So use the incoming level
to figure out when to set the int bits and when to clear it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This doesn't currently generate any interrupts (as there doesn't appear
to be any documentation to *when* it would even do so), but since the
HRM does say an interrupt line exists between the OTP and the SIC, add
one for completeness sake. This will make a follow up patch easier.
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>
The current implementation attempts to handle the 16bit sign extension
itself. Unfortunately, it gets it right in some cases. So rather than
fix that logic, just drop it in favor of using 16bit signed casts. Now
gcc will take care of getting the logic right.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The current handling of the subtraction insn with the RND12 modifier
works when saturation isn't involved. So add handling for this edge
case to match the hardware.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The 16bit add/sub insns missed setting the VS bit in ASTAT whenever the
V bit was also set.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Makes it a lot easier to find out what's going on with interrupt lines
if the ports have tracing output.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
We need the DIR bit cleared, not set, in order for the pin to be treated
as an input.
When looking up the data value, we need to shift the "level" value over by
"my_port" rather than "bit" as the latter has already been shifted over.
We also should normalize the "level" coming in from the outside worlds to
the set of {0,1} since those are the only values that matter to GPIOs.
We need the BOTH bit set, not cleared, in order for the pin to trigger
on both edges.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The clear/set/toggle MMRs aren't backed by "real" data; they implicitly
perform bit operations on the associated data register. So when we go
to process writes to them, we need to adjust the pointer accordingly so
that the actual backing data is modified.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When I originally wrote the w1c helper funcs, I used it in a few places.
Then I forgot how it worked and when I later documented it, I described
the 3rd arg in the exact opposite way it is actually used. This error
propagated to a bunch of devices registers that were not explicitly
tested (a bunch of the devices are stubs which merely exist to say "no
device is connected" to make device drivers happy).
So once the documentation is unscrewed, fix all of the broken call sites.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
We'll need these bits in an upcoming patch, so map out the whole
LSR MMR now.
Fix up indentation style while we're here.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The Blackfin PRM says that the top 8 bits of the accumulator must be
cleared when using the VIT_MAX insn, so the sim has followed this spec.
Matching the hardware behavior though when the high bits are not cleared
is easy to do and doesn't break existing behavior, so go for it.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The Blackfin PRM does not cover this case, but the hardware is clear: even
if the search criteria is not met (and thus a new 16bit value is loaded up
into the accumulator), the accumulator undergoes 16bit sign extension. So
simply reload the low signed 16bits in that case.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The Acc=-Acc insn can overflow or carry with edge values, so make sure
we update the ASTAT bits accordingly to match the hardware. Also fix
a thinko where we always updated AC0 even when working with A1 regs.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When encoding the SIC/pin info into unique input port ids, I used bases
of 100 when I meant to use 0x100. Rather than simply fix the decoding
math in the different functions, create a few helper macros to simplify
the SIC/pin encoding and decoding steps. This makes the resulting tables
nice & clear.
And now that pins are clear, the 533 and 537 port_event handlers may
easily be merged into one.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The hardware allows the byteop[123]p insns to use the same src reg pair,
so remove the combination check in the sim.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The bus addresses have to be valid numbers, so 'g' and 'h' won't work.
Oddly, the common code silently ignored this which is why I didn't notice
in the first place.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
do not invoke the host's functionality directly. Invoke
sim_io_stat() instead of stat() for implementing TARGET_SYS_stat.
Implement TARGET_SYS_fstat, TARGET_SYS_rename, and TARGET_SYS_unlink.
We weren't updating AZ when doing a 16bit add or sub insn. Implement it.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
No point in moving unchanged acc values to the acc regs, and avoid
updating the acc ASTAT bits when only reading. This fixes incorrect
changing of the ASTAT bits when they're only being read.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The current dsp mult handler does not take care of overflows which turn
values negative (and thus set AN in ASTAT). So implement it.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The current dsp mult handler does not take care of overflows and updating
the V ASTAT bit. So implement it.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
When testing ASTAT regs, specific bit differences carry a lot more meaning
than when checking the value of a data register. So automatically decode
the bits of the two values and print things out so that people don't have
to manually do it themselves every time.
Signed-off-by: Robin Getz <robin.getz@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The saturation behavior with fract modes differs from non-fract modes.
Signed-off-by: Robin Getz <robin.getz@analog.com>
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>
gdb/ChangeLog
* remote-sim.c (gdbsim_store_register): Update API to
sim_store_register to check more error conditions.
include/gdb/ChangeLog
* remote-sim.h (sim_store_register): Update the API
documentation for this function.
sim/erc32/ChangeLog
sim/h8300/ChangeLog
sim/m32c/ChangeLog
sim/mn10300/ChangeLog
sim/ppc/ChangeLog
sim/rx/ChangeLog
sim/v850/ChangeLog
* ???.c (sim_store_register): Update return value to
match new API.
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>
