| Age | Commit message (Collapse) | Author | Files | Lines |
|
Just to hammer on anything at once, and hopefully catch weird
interactions if they exist.
|
|
|
|
When compiling, define the number of harts. This means we only need to
allocate a lot of stack if there are a lot of harts.
|
|
|
|
Targets now contain an array of harts. When running a regular test, one
hart is selected to run the test on while the remaining harts are parked
in a safe infinite loop.
There's currently only one test that tests multicore behavior, but there
could be more.
The infrastructure should be able to support heterogeneous multicore,
but I don't have a target like that to test with.
|
|
Then for targets that can't handle this because they don't implement
hmode, add a target setting that allows that to be specified.
|
|
This shouldn't affect triggers set by the debugger, because running code
can't change those. When it does affect them, it breaks Hwbp1 which sets
the breakpoint before running the program.
|
|
At least in the test programs. There are other places where this causes
trouble as well.
|
|
|
|
I've added an additional linker relaxation that relaxes two instruction
pc-relative sequences to one instruction gp relative sequences when
possible. This sequence now optimizes the initial gp generation to
mv gp, gp
which is obviously bogus. The fix is to disable relaxations when
setting up gp, preventing the linker from relaxing away this setup code.
|
|
This changed a while ago in binutils.
|
|
All tests pass on spike32 and spike64 again.
|
|
|
|
If the last test leaves some triggers set they should be cleaned up.
|
|
Now gdb can call functions and change strings.
|
|
|
|
I did comment out a couple.
|