Open jfustos opened 2 months ago
Status Flag 'Pre-Test Inspection' - - This Pull Request Requires Inspection... The code must be inspected by a member of the Team before Testing/Merging NO INSPECTION HAS BEEN PERFORMED ON THIS PULL REQUEST! - This PR must be inspected by setting label 'AT: PRE-TEST INSPECTED'.
Status Flag 'Pre-Test Inspection' - SUCCESS: The last commit to this Pull Request has been INSPECTED by label AT: PRE-TEST INSPECTED! Autotester is Removing Label; this inspection will remain valid until a new commit to source branch is performed.
Status Flag 'Pull Request AutoTester' - Testing Jenkins Projects:
Status Flag 'Pull Request AutoTester' - Jenkins Testing: 1 or more Jobs FAILED
Note: Testing will normally be attempted again in approx. 4 Hrs. If a change to the PR source branch occurs, the testing will be attempted again on next available autotester run.
@jfustos These are the errors: osx
./decoder/vriscv64gdb.h:1129:51: error: use of undeclared identifier 'SOCK_CLOEXEC'
listen_fd = socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP);
makedist
decoder/vriscv64decoder.cc:19:10: fatal error: decoder/vriscv64gdb.h: No such file or directory
#include "decoder/vriscv64gdb.h"
^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[5]: *** [Makefile:1327: decoder/vriscv64decoder.lo] Error 1
make[5]: *** Waiting for unfinished jobs....
In file included from vanadis.cc:19:
inst/vinstall.h:88:10: fatal error: inst/vgetregcallable.h: No such file or directory
#include "inst/vgetregcallable.h"
^~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[5]: *** [Makefile:1327: vanadis.lo] Error 1
In file included from ./decoder/vmipsdecoder.h:22,
from decoder/vmipsdecoder.cc:19:
./inst/vinstall.h:88:10: fatal error: inst/vgetregcallable.h: No such file or directory
#include "inst/vgetregcallable.h"
First attempt at implementing gdb for Vanadis
This feature implements a GDB server within Vanadis. This feature is turned off and on by options in the sst python script. Breakpoints are detected and halted between the front and backends of the pipeline. Once a breakpoint is halted it first waits for the backend to clear, ensuring that it is not a speculative breakpoint. Once it is not speculative, the server takes over. A socket is opened that a client can communicate with a.k.a. the GDB client we all know and love. GDB request, like register dumps, are fulfilled by injecting instructions into the pipeline. Breakpoints are tracked within the GDB module. Execution is restored simply by letting the breaked instructions flow through until the address of the instruction changes. Testing has been done only on a few small programs. Each individual simulated core has its own GDB server, which needs to be connected to over a different port and from a different client, so you can single step two cores at the same time, but you will need 2 windows to do that.