There was apparently a confusion which cpu model uses
compressed JAL and which ADDIW. Fixed that in execute_c,
case MATCH_C_JAL | MATCH_C_ADDIW.
Fixes 3224e32fb8 ("sim: riscv: Add support for compressed integer instructions")
Approved-By: Andrew Burgess <aburgess@redhat.com>
Various gcc test cases fail due to the stack
alignment of 16 bytes is expected by gcc,
causing issues mostly with vararg functions,
e.g.
FAIL: gcc.c-torture/execute/nest-align-1.c -O0 execution test
FAIL: gcc.c-torture/execute/nest-stdar-1.c -O0 execution test
FAIL: gcc.c-torture/execute/va-arg-12.c -O0 execution test
FAIL: gcc.c-torture/execute/va-arg-15.c -O0 execution test
FAIL: gcc.c-torture/execute/va-arg-16.c -O0 execution test
FAIL: gcc.c-torture/execute/va-arg-17.c -O0 execution test
FAIL: gcc.c-torture/execute/va-arg-20.c -O0 execution test
FAIL: gcc.c-torture/execute/va-arg-26.c -O0 execution test
...
Approved-By: Andrew Burgess <aburgess@redhat.com>
The uncompressed EBREAK instruction does not work
correctly this way, and the comment saying that
GDB expects us to step over EBREAK is just wrong.
The PC was always 4 bytes too high, which skips one
instruction at break and step over commands, and
causes complete chaos. The compressed EBREAK was
already implemented correctly.
Tested by using gdb's "target sim" and single-stepping.
Approved-By: Andrew Burgess <aburgess@redhat.com>
EVENT_MAX is defined as 0x7FFFFFFF (INT_MAX) in winuser.h, so when
building on Windows, the value is overridden and compilation fails
because the array size of evbuf is too large.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28476
Approved-By: Tom Tromey <tom@tromey.com>
Seen with --enable-maintainer-mode.
make[3]: *** No rule to make target '.../sim/ppc/Makefile.in', needed
by 'ppc/stamp-pk'. Stop.
* sim/ppc/local.mk (stamp-pk): Depend on local.mk not
Makefile.in.
* Makefile.in: Regenerate.
Approved-By: Tom Tromey <tom@tromey.com>
Added support for simulation of compressed integer instruction set ("c").
Added test file sim/testsuite/riscv/c-ext.s to test compressed instructions.
The compressed instructions are available for models implementing C extension.
Such as RV32IC, RV64IC, RV32GC, RV64GC etc.
Approved-By: Andrew Burgess <aburgess@redhat.com>
This patch removes support for the two instructions above from the GNU
simulator, including the corresponding tests. These instructions do
not really exist in BPF and are not recognized as such by the kernel
verifier. This has now been pointed out during the standardization of
the BPF ISA.
Signed-off-by: Jose E. Marchesi <jose.marchesi@oracle.com>
The op struct includes an array of strings, but doesn't use braces
around that array when initializing. This causes a ton of warnings
when using -Wmissing-braces. Add them to fix.
The code this tool generates is the same before & after.
The match_never() function has been removed and thus step_once() crashes
during instruction decoding. Fixed it by checking for null pointer before
invoking function attached to match_func member of riscv_opcode structure
Some compilers warn in the frv code:
sem.c:24343:41: error: incompatible function pointer types passing
'void (SIM_CPU *, UINT, UDI)' (aka 'void (struct _sim_cpu *, unsigned int, unsigned long)')
to parameter of type
'void (*)(SIM_CPU *, UINT, DI)' (aka 'void (*)(struct _sim_cpu *, unsigned int, long)') [-Wincompatible-function-pointer-types]
This is due to frvbf_h_acc40U_set using UDI for setting the new value,
but using the common sim_queue_fn_di_write API which uses DI. The same
size, but different sign. We could change frvbf_h_acc40U_set to take a
DI without changing behavior in practice: the UDI is already passed via
the queue function which accepts a DI, and frvbf_h_acc40U_set already
casts the input to UDI before running any operations on it. However,
these files are all generated, so manual changes here would be reverted.
Seems like we can only change the register type for all APIs in the cpu
definition. This builds cleanly, and passes sim unittests. Not sure if
it's 100% the answer, but seems to be the best we have currently.
Bug: https://sourceware.org/PR29752
m32c/cpu.h defines mem as enum value, which causes GCC 14 to emit
sim/m32c/gdb-if.c: In function ‘sim_read’:
sim/m32c/gdb-if.c:162:33: error: declaration of ‘mem’ shadows a previous local [-Werror=shadow=local]
162 | sim_read (SIM_DESC sd, uint64_t mem, void *buf, uint64_t length)
| ~~~~~~~~~^~~
In file included from ../../binutils-gdb/sim/m32c/gdb-if.c:38:
sim/m32c/cpu.h:83:3: note: shadowed declaration is here
83 | mem,
| ^~~
Fix this by renaming mem to addr in all sim_read and sim_write functions.
Most already used addr instead of mem. In one file, sim/rx/gdb-if.c, this
also meant renaming the local addr variable to vma.
With GCC 14 -Werror=shadow=compatible-local flags the reuse of single
capital letters used in aarch64/cpustate.h enums
88 | expand_logical_immediate (uint32_t S, uint32_t R, uint32_t N)
| ~~~~~~~~~^
In file included from ../../binutils-gdb/sim/aarch64/aarch64-sim.h:27,
from ../../binutils-gdb/sim/aarch64/simulator.c:33:
217 | N = 1 << N_IDX
| ^
sim/aarch64/simulator.c: In function ‘expand_logical_immediate’:
sim/aarch64/simulator.c:88:60: error: declaration of ‘N’ shadows a previous local [-Werror=shadow=compatible-local]
sim/aarch64/cpustate.h:217:3: note: shadowed declaration is here
include/opcode/cr16.h defines cc as an enum value, which causes GCC 14
to warn
sim/cr16/simops.c: In function ‘cond_stat’:
sim/cr16/simops.c:138:26: error: declaration of ‘cc’ shadows a previous local [-Werror=shadow=local]
138 | static int cond_stat(int cc)
| ~~~~^~
In file included from ../../binutils-gdb/sim/cr16/cr16-sim.h:26,
from ../../binutils-gdb/sim/cr16/simops.c:39:
sim/../include/opcode/cr16.h:149:3: note: shadowed declaration is here
149 | cc,
| ^~
Fix this by renaming cc in cr16/simops.c to cond.
We have APIs in sim-endian for working with 128-bit values like this code
is already doing for 8/16/32/64-bit values. Switch over to that to make
it a bit simpler, and drop the WITH_ALTIVEC check. The code probably is
only used when altivec is enabled, but it doesn't add much to always
compile it in, and avoids #ifdef rot by not actually compiling it.
This code creates a small buffer on the stack w/alloca, then proceeds to
write to it with a cast to a pointer type based on the register type, then
reads from it with a cast to a pointer type based on the register size.
gcc will flags only one of these lines as "maybe used uninitialized", but
it seems to track back to this memory abuse.
Create a large union with all the possible types that this code will read
or write as, and then use those. It's a bit ugly, but is probably better
than using raw memcpy's everywhere.
commit 1d506c26d9
Update copyright year range in header of all files managed by GDB
updated gnulib/Makefile.am but didn't regenerate gnulib/Makefile.in
also sim/Makefile.in was updated, but the Copyright hunks/years
were off. The first hunk comes from automake 1.15.1 header-vars.am
and so should have 2017 as last year, the second hunk does come from
sim/Makefile.am and so should have 2024 as last year.
* gnulib/Makefile.in: Regenerate.
* sim/Makefile.in: Likewise.
The following change broke simulator testsuite with host GCC 13:
commit 435ad222b3
sim: warnings: compile build tools with -Werror too
Host GCC13 complains about missing function prototypes:
binutils/sim/testsuite/common/bits-gen.c:26:1: error: no previous prototype for ‘gen_struct’ [-Werror=missing-prototypes]
26 | gen_struct (void)
| ^~~~~~~~~~
Fix by making the functions static, which instructs the compiler that
there is no need for a prototype.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
The m32r trap code was written for a 32-bit Linux host (and really, one
whose Linux ABI matched pretty exactly). This has lead to conversions
between integers and pointers which breaks down hard on 64-bit hosts.
Clean up some of the functions where possible to avoid unnecessary
conversions, use uintptr_t to cast 32-bit target pointers to host
pointers in some places, and just stub out a few functions that can't
easily be salvaged currently when sizeof(void*) is not 32-bits. This
is a bit ugly, but lets us enable warnings for the whole file.
The ftime() function has been deprecated since POSIX-1-2004, and
removed in POSIX.1-2008. It's also been deprecated/removed in glibc
since 2.33. POSIX has always said the function is not portable, and
its return value, timezone, and dstflag fields are unspecified. Even
if Linux/glibc & m32r had defined behavior, those aren't the host for
the sim runtime.
So let's stop using the function and switch to clock_gettime. gnulib
already has detection support for it, and it's been around since at
least POSIX-1-2004.
While gcc propagates the printf attribute via the typedef, clang
doesn't seem to, so add it to the prototypes themselves too. We
still keep it on the prototype for cases where it's used as a
variable.
The HAVE_DECL_xxx defines are always defined to 0 or 1. The current
defines.h logic assumes every HAVE_xxx symbol is only defined iff it's
defined to 1 which causes this to break. Tweak the sed logic to only
match defines of 1.
Add support for compiling build tools with various -Werror settings.
Since the tools don't compile cleanly with the same set of flags as
the rest of the sim code, we need to maintain & test a separate list.
Only bother when not cross-compiling so we don't have to test all the
flags against the build compiler. This should be good enough for our
actual development flows.
Leave the igen code in place as it's meant to be used with newer
(to-be-written) code ported from the ppc version.
The sh code isn't really necessary as the opcodes enums have been
maintained independently from here, and the lists are out-of-sync
already.
This logic dates back to the original import, and seems to be for
handling systems where `rm -f` (i.e. no files) would error out.
None of that is relevant for us with current automake, so drop it.
Some compilers don't understand the semctl API and think it's an input
argument even when it's used as an output, and then complains that it
is being used uninitialized. Zero it out explicitly to workaround it.
This adds some runtime overhead, but should be fairly minor as it's a
small stack buffer, and shouldn't be that relevant relative to all the
other logic in these functions.
The cgen code uses DI as int64_t and UDI as uint64_t. The DI macros
are used to construct 64-bit values from 32-bit values (for the low
and high parts). The MAKEDI macro casts the high 32-bit value to a
signed 32-bit value before shifting. If this created a negative
value, this would be undefined behavior according to the C standard.
All we care about is shifting the 32-bits as they are to the high
32-bits, not caring about sign extension (since there's nothing left
to shift into), and the low 32-bits being empty. This is what we
get from shifting an unsigned value, so cast it to unsigned 32-bit
to avoid undefined behavior.
While we're here, change the SETLODI macro to truncate the lower
value to 32-bits before we set it. If it was passing in a 64-bit
value, those high bits would get included too, and that's not what
we want.
Similarly, tweak the SETHIDI macro to cast the value to an unsigned
64-bit instead of a signed 64-bit. If the value was only 32-bits,
the behavior would be the same. If it happened to be signed 64-bit,
it would trigger the undefined behavior too.
Rename the temp var to avoid shadowing another one:
.../sim/cris/semcrisv10f-switch.c:11032:22: error: declaration of ‘tmp_tmpb’ shadows a previous local [-Werror=shadow=compatible-local]
11032 | tmp_tmpb = ({ SI tmp_tmpb;
| ^~~~~~~~
.../sim/cris/semcrisv10f-switch.c:11031:24: note: shadowed declaration is here
11031 | tmp_tmpres = ({ SI tmp_tmpb;
| ^~~~~~~~
The condition & swap code decoder only checks known bits and sets
based on that. If the variable is out of range, it ends up returning
uninitialized data. Turn that case into a hard error.
This fixes build warnings like:
sim/cris/semcrisv10f-switch.c:13115:11: error:
variable 'tmp_condres' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
The common igen code was forked from the ppc long ago. The filter
module is still pretty similar in API, so we can unfork them with
a little bit of effort.
The filter.c module is still here because of the unique it_is API.
The common igen code doesn't seem to have an equiv API as this only
operates on two strings and not an actual filter object, and it's
easy enough to leave behind to unfork the rest.
The common igen code was forked from the ppc long ago. The lf module
is still pretty similar in API, so we can unfork them with a little
bit of effort.
Some of the generated ppc code is now slightly different, but that's
because of fixes the common igen code has gained, but not the ppc igen
code (e.g. fixing of #line numbers).
The ppc code retains lf_print__c_code because the common igen code
rewrote the logic to a new table.c API. Let's delay that in the ppc
code to at least unfork all this code.
Add standard multiple inclusion protection, and add a few missing
local includes when one header uses another. This isn't complete,
but fixes some short comings seen when merging the ppc igen.
The common sim-endian is a forked & updated version of the ppc code.
Fortunately, they didn't diverge from the basic APIs, so they are
still compatible, which means we can just delete the ppc version now
that the build env is merged at the top-level.
This is a bit redundant for most ports as they go through sim-basics.h
which always includes sim-types.h before including sim-endian.h, but in
order to unify ppc's sim-endian code, we need this include here. Plus,
it's the directly we generally want to go to get away from one header
that defines all APIs and causes hard to untangle dependencies.
The common/ code has macros with the same name but different behavior:
it's for declaring integer constants as 64-bit, not for casting them.
Rename ppc's local variant since it's only used in this file in order
to avoid conflicts.
Bernd Edlinger
Orgad Shaneh
Alan Modra
Jaydeep Patil
Jose E. Marchesi
Mike Frysinger
Mark Wielaard
Dimitar Dimitrov
Andrew Burgess