The verbose argument has always been an int treated as a bool, so
convert it to an explicit bool. Further, update the API docs to
match the reality that the verbose value is actually used by some
of the internal modules.
We have many uses of sys/stat.h that are unprotected by HAVE_SYS_STAT_H,
so this is more formalizing the reality that we require this header.
Since we switched to gnulib, it guarantees that a sys/stat.h exists
for us to include, so we're doubly OK.
All the runtimes were only initializing a single CPU. When SMP is
enabled, things quickly crash as none of the other CPU structs are
setup. Change the default from 0 to the compile time value.
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so move it all out to a new header which only
this port will include.
We've been using SIM_ADDR which has always been 32-bit. This means
the upper 32-bit address range in 64-bit sims is inaccessible. Use
64-bit addresses all the time since we want the APIs to be stable
regardless of the active arch backend (which can be 32 or 64-bit).
The length is also 64-bit because it's completely feasible to have
a program that is larger than 4 GiB in size/image/runtime. Forcing
the caller to manually chunk those accesses up into 4 GiB at a time
doesn't seem useful to anyone.
Bug: https://sourceware.org/PR7504
These headers define the register numbers for each port to implement
the sim_fetch_register & sim_store_register interfaces. While gdb
uses these, the APIs are part of the sim, not gdb. Move the headers
out of the gdb/ include namespace and into sim/ instead.
When reading/writing arbitrary data to the system's memory, the unsigned
char pointer type doesn't make that much sense. Switch it to void so we
align a bit with standard C library read/write functions, and to avoid
having to sprinkle casts everywhere.
When reading/writing arbitrary data to the system's memory, the unsigned
char pointer type doesn't make that much sense. Switch it to void so we
align a bit with standard C library read/write functions, and to avoid
having to sprinkle casts everywhere.
There are two places in the h8300 simulator where we assign a variable
to itself. Clang gives a warning for this, which is converted into an
error by -Werror.
Silence the warning by removing the self assignments. As these
assignments were in a complex if/then/else tree, rather than try to
adjust all the conditions, I've just replaced the self assignments
with a comment and an empty statement.
The upstream GCC tester has showed spurious execution failures on the
H8 target for the H8/SX multilibs. I suspected memory corruption or an
uninitialized variable early as the same binary would sometimes work and
sometimes it got the wrong result. Worse yet, the point where the test
determined it was getting the wrong result would change.
Because it only happened on the H8/SX variant I was able to zero in on
the "mova" support and the "short form" of those instructions in particular.
As the code stands it checks if code->op3.type == 0 to try and identify cases
where op3 wasn't filled in and thus we've got the short form of the mova
instruction.
But for the short-form of those instructions we never set any of the "op3"
data structure. We get whatever was lying around -- it's usually zero and
thus things usually work, but if the stale data was nonzero, then we'd
fail to recognize the instruction as a short-form and fail to set up the
various fields appropriately.
I initially initialized the op3.type field to zero, but didn't like that
because it was inconsistent with how other operands were initialized.
Bringing consistency meant using -1 as the initializer value and adjusting
the check for short form mova appropriately.
I've had this in the upstream GCC tester for perhaps a year at this point
and haven't seen any of the intermittent failures again.
We use the program argv to both find the program to run (argv[0]) and
to hold the arguments to the program. Most of the time this is fine,
but if we want to let programs specify argv[0] independently (which is
possible in standard *NIX programs), this double duty doesn't work.
So let's split the path to the program to run out into a separate
field by itself. This simplifies the various sim_open funcs too.
By itself, this code is more of a logical cleanup than something that
is super useful. But it will open up customization of argv[0] in a
follow up commit. Split the changes to make it easier to review.
The sim-basics.h is too big and includes too many things. This leads
to some arch's sim-main.h having circular loop issues with defs, and
makes it hard to separate out common objects from arch-specific defs.
By splitting up sim-basics.h and killing off sim-main.h, it'll make
it easier to separate out the two.
The m4 macro has 2 args: the "wire" settings (which represents the
hardwired port behavior), and the default settings (which are used
if nothing else is specified). If none are specified, the arch is
expected to support both, and the value will be probed based on the
user runtime options or the input program.
Only two arches today set the default value (bpf & mips). We can
probably let this go as it only shows up in one scenario: the sim
is invoked, but with no inputs, and no user endian selection. This
means bpf will not behave like the other arches: an error is shown
and forces the user to make a choice. If an input program is used
though, we'll still switch the default to that. This allows us to
remove the WITH_DEFAULT_TARGET_BYTE_ORDER setting.
For the ports that set a "wire" endian, move it to the runtime init
of the respective sim_open calls. This allows us to change the
WITH_TARGET_BYTE_ORDER to purely a user-selected configure setting
if they want to force a specific endianness.
With all the endian logic moved to runtime selection, we can move
the configure call up to the common dir so we only process it once
across all ports.
The ppc arch was picking the wire endian based on the target used,
but since we weren't doing that for other biendian arches, we can
let this go too. We'll rely on the input selecting the endian, or
make the user decide.
The sim-basics.h is too big and includes too many things. This leads
to some arch's sim-main.h having circular loop issues with defs, and
makes it hard to separate out common objects from arch-specific defs.
By splitting up sim-basics.h and killing off sim-main.h, it'll make
it easier to separate out the two.
Start with splitting out sim/callback.h.
The defs.h header will take care of including the various config.h
headers. For now, it's just config.h, but we'll add more when we
integrate gnulib in.
This header should be used instead of config.h, and should be the
first include in every .c file. We won't rely on the old behavior
where we expected files to include the port's sim-main.h which then
includes the common sim-basics.h which then includes config.h. We
have a ton of code that includes things before sim-main.h, and it
sometimes needs to be that way. Creating a dedicated header avoids
the ordering mess and implicit inclusion that shows up otherwise.
A random grab bag of minor fixes to enable -Werror for this port.
Disable h8_set_macS for now as it's unused.
Initialize trace & intMask before using them.
Mark local set_h8300h function static.
GCC gives a -Wsequence-point warning for this code in the h8300 sim.
The bug is that memory_size is both assigned and used in the same
expression. The fix is to assign after the print.
sim/h8300/ChangeLog
2021-04-08 Tom Tromey <tom@tromey.com>
* compile.c (init_pointers): Fix sequence point warning.
The h8300 sim has its own implementation for memory handling that I'd
like to replace with the common sim memory code. However, it's got a
weird bit of code it calls "eightbit mem" that makes this not as easy
as it would otherwise be. The code has this comment:
/* These define the size of main memory for the simulator.
Note the size of main memory for the H8/300H is only 256k. Keeping it
small makes the simulator run much faster and consume less memory.
The linker knows about the limited size of the simulator's main memory
on the H8/300H (via the h8300h.sc linker script). So if you change
H8300H_MSIZE, be sure to fix the linker script too.
Also note that there's a separate "eightbit" area aside from main
memory. For simplicity, the simulator assumes any data memory reference
outside of main memory refers to the eightbit area (in theory, this
can only happen when simulating H8/300H programs). We make no attempt
to catch overlapping addresses, wrapped addresses, etc etc. */
I've read the H8/300 Programming Manual and the H8/300H Software Manual
and can't find documentation on it. The closest I can find is the bits
about the exception vectors, but that sounds like a convention where the
first 256 bytes of memory are used for a special purpose. The sim will
actually allocate a sep memory buffer of 256 bytes and you address it by
accessing anywhere outside of main memory. e.g. I would expect code to
access it like:
uint32_t *data = (void *)0;
data[0] = reset_exception_vector;
not like the sim expects like:
uint8_t *data = (void *)0x1000000;
data[0] = ...;
The gcc manual has an "eightbit_data" attribute:
Use this attribute on the H8/300, H8/300H, and H8S to indicate that
the specified variable should be placed into the eight-bit data
section. The compiler generates more efficient code for certain
operations on data in the eight-bit data area. Note the eight-bit
data area is limited to 256 bytes of data.
And the gcc code implies that it's accessed via special addressing:
eightbit_data: This variable lives in the 8-bit data area and can
be referenced with 8-bit absolute memory addresses.
I'm fairly certain these are referring to the 8-bit addressing modes
that allow access to 0xff00 - 0xffff with only an 8-bit immediate.
They aren't completely separate address spaces which this eightbit
memory buffer occupies.
But the sim doesn't access its eightbit memory based on specific insns,
it does it purely on the addresses requested.
Unfortunately, much of this code was authored by Michael Snyder, so I
can't ask him :(. I asked Renesas support and they didn't know:
https://renesasrulz.com/the_vault/f/archive-forum/6952/question-about-eightbit-memory
So I've come to the conclusion that this was a little sim-specific hack
done for <some convenience> and has no relation to real hardware. And
as such, let's drop it until someone notices and can provide a reason
for why we need to support it.
Since we require C11 now, we can assume many headers exist, and
clean up all of the conditional includes. It's not like any of
this code actually accounted for the headers not existing, just
whether we could include them.
The strings.h cleanup is a little nuanced: it isn't in C11, but
every use of it in the codebase will include strings.h only if
string.h doesn't exist. Since we now assume the C11 string.h
exists, we'll never include strings.h, so we can delete it.
This is in preparation for converting h8300 over to the common memory
framework. It's not clear how much of a speed gain this was providing
in the first place -- a naive test of ~400k insns (using shlr.s) shows
that this code actually slowed things down a bit.
If anyone really cares about h8300 anymore, they can migrate to the
common insn caching logic.
Fix a long standing todo where we let getopt write directly to stderr
when an invalid option is passed. Use the sim io funcs instead as they
go through the filtered callbacks that gdb wants.
We can leverage the cpu->regs array rather than going through the
function helpers to get nice compact code.
Further, fix up the return values: return -1 when we can't find a
register (and let the caller write out warnings), return 2/4 when
we actually write out that amount, and handle the zero reg.
This array isn't used anywhere, and the init phase actually corrupts
some memory because the array has 18 elements but tries to set the
19th (ZERO) position.
Other than the nice advantage of all sims having to declare one fewer
common function, this also fixes leakage in pretty much every sim.
Many were not freeing any resources, and a few were inconsistent as
to the ones they did. Now we have a single module that takes care of
all the logic for us.
Most of the non-cgen based ones could be deleted outright. The cgen
ones required adding a callback to the arch-specific cleanup func.
The few that still have close callbacks are to manage their internal
state.
We do not convert erc32, m32c, ppc, rl78, or rx as they do not use
the common sim core.
This sets up the sim_state structure and the cpu member to match what we
do in most other sims, and what the common code suggests. This is a step
to unifying on the sim-cpu.o object.
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.
Many of the simulators change the SIGINT handler.
E.g., moxie/interp.c:
sigsave = signal (SIGINT, interrupt);
However, this is unnecessary.
remote-sim.h already provides an API for asynchronously stopping
a sim; and both gdb and the drivers (run.c and nrun.c at least,
I didn't check the others) install a SIGINT handler which
calls this method.
URL: https://sourceware.org/bugzilla/show_bug.cgi?id=16450
Reported-by: Tom Tromey <tromey@redhat.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
* 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.
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>
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.
As pointed out by Sandra Loosemore, a bunch of targets define sim_write
themselves instead of using the common/ code. So constify them too.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
