hpsresearchgroup / scarab Goto Github PK

Describe the bug
When running a generated checkpoint from SPEC 2006, Scarab hangs because of an error with Pin's parent and child injection modes.

Writing data to all regions ...
Updating region protection fields ...
Loading the floating-point state ...
Loading the architectural registers ...
Detaching ptrace from the child process ...
E: Attach to pid 20057 failed.
E:   The Operating System configuration prevents Pin from using the default (parent) injection mode.
E:   To resolve this, either execute the following (as root):
E:   $ echo 0 > /proc/sys/kernel/yama/ptrace_scope
E:   Or use the "-injection child" option.
E:   For more information, regarding child injection, see Injection section in the Pin User Manual.
E: 

I can't execute the echo command because I don't have root access on the lab machines and the "-injection child" option doesn't work and just outputs this error instead:

E: unknown option "child"

To Reproduce
Steps to reproduce the behavior:

1. Generate SPEC 2006 Checkpoints
2. Run command: python3 bin/scarab_launch.py --params src/PARAMS.kaby_lake --simdir test_run --checkpoint <PATH TO SPEC CHECKPOINTS>/bzip2_06/test/bzip2_06_test0_checkpoint3_0.28053003572169843_6900001396 --scarab_args='--inst_limit 30000000'
3. See error on Terminal

Expected behavior
Scarab should run and simulate that checkpoint

Desktop (please complete the following information):

• OS: Ubuntu (jalad lab machine)
• Browser: Chrome
• Version: Ubuntu 18.04, Chrome 96

Hi,
I am new to Scarab and having difficulty debugging the simulator, any help is really appreciated.
I have enabled the simulator with 3 levels of caches and designed a wrapper similar to that of Ramulator to my own prefetchers.
Now, I have one prefetcher per level. The way my prefetchers work is that after finding a candidate, it is added to prefetchers queue using a function call to one of the "pref_addto_ul1req_queue_set", "pref_addto_umlc_req_queue", "pref_addto_dl0req_queue" functions.

The problem is that the simulation stops and breaks after some instructions dumping the following outputs:

'/home/cc/scarab/src/sim.c:304: ASSERT FAILED (P=0 O=280902 I=253982 C=100180000): cycle_count - last_forward_progress[proc_id] <= (Counter)FORWARD_PROGRESS_LIMIT
/home/cc/scarab/src/sim.c:304: ASSERT FAILED (P=0 O=280902 I=253982 C=100180000): last_forward_progress:170000
Obtained 6 stack frames.
/home/cc/scarab/src/scarab(+0x4ce67) [0x555b1b0cfe67]
/home/cc/scarab/src/scarab(+0x17ab78) [0x555b1b1fdb78]
/home/cc/scarab/src/scarab(+0x17d0f8) [0x555b1b2000f8]
/home/cc/scarab/src/scarab(+0x14f80d) [0x555b1b1d280d]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7fbbbb33bbf7]
/home/cc/scarab/src/scarab(+0x4c9ca) [0x555b1b0cf9ca]
../pin_lib/message_queue_interface_lib.cc:161 (Client)$ Socket closed unexpectedly on read. Scarab process probably died.: Success
RETURN CODE 15: /home/cc/scarab/src/scarab --num_cores 1 --pin_exec_driven_fe_socket /tmp/Scarab_Temp_WorkDir_peisoias/socket --bindir /home/cc/scarab/bin --inst_limit 30000000
Error: TERMINATING BECAUSE NON-ZERO RETURN CODE FOR:
/home/cc/scarab/src/scarab --num_cores 1 --pin_exec_driven_fe_socket /tmp/Scarab_Temp_WorkDir_peisoias/socket --bindir /home/cc/scarab/bin --inst_limit 30000000
Notify: Scarab run terminated, cleaning up...'

I tried to debug with the following setting:
--debug_inst_start 253900 --debug_inst_stop 253982 --debug_cycle_start 0 --debug_cycle_stop -1 --debug_memory 1 --debug_pref 1
However, I could not figure out what is wrong. Also, with gdb I could not find the reason. Do you have any tips for me?

Also, I should add that there would be no problem, if I disable the L1 (ld0) prefetcher. I separately confirmed the simulation is finished with mlc+LLC prefetchers, only LLC prefetcher, and only mlc prefetcher.

By looking at the code, I noticed in Scarab we have another module for L1 prefetcher (l2l1prefetcher); separated from other prefetchers. I could not figure out why this should be seperated?

Asking a question on the Scarab Issues page allows the entire Scarab community to benefit from the discussion. It also decreases response time as any of the Scarab administrators can answer these questions.

Please type your questions here!

In line 215 in decoder.c, direct branches that suffer from a btb_miss that are not taken trigger a redirect. I believe this is a bug. If a direct branch is not taken (fall through path) then scarab should not care about whether there was a BTB miss. Since rarely/never taken branches are not put into the BTB this may lead to inaccuracies. The suggested fix is to also check whether the branch was taken. This also applies to indirect branches in line 227.

// since it is not indirect, redirect the input stream if it was a btb
// miss
if(op->oracle_info.btb_miss && !bf) {

adding @5surim @petervbraun to this thread

Describe the bug
Trace generator pintool does not compile.

To Reproduce

cd src/pin/pin_trace
make

siavash@Siavash:~/scarab/src/pin/pin_trace$ make
mkdir -p obj-intel64/
make objects
make[1]: Entering directory '/home/siavash/scarab/src/pin/pin_trace'
make[1]: Nothing to be done for 'objects'.
make[1]: Leaving directory '/home/siavash/scarab/src/pin/pin_trace'
make libs
make[1]: Entering directory '/home/siavash/scarab/src/pin/pin_trace'
make[1]: Nothing to be done for 'libs'.
make[1]: Leaving directory '/home/siavash/scarab/src/pin/pin_trace'
make dlls
make[1]: Entering directory '/home/siavash/scarab/src/pin/pin_trace'
make[1]: Nothing to be done for 'dlls'.
make[1]: Leaving directory '/home/siavash/scarab/src/pin/pin_trace'
make apps
make[1]: Entering directory '/home/siavash/scarab/src/pin/pin_trace'
make[1]: Nothing to be done for 'apps'.
make[1]: Leaving directory '/home/siavash/scarab/src/pin/pin_trace'
make tools
make[1]: Entering directory '/home/siavash/scarab/src/pin/pin_trace'
g++ -Wall -Werror -Wno-unknown-pragmas -D__PIN__=1 -DPIN_CRT=1 -fno-stack-protector -fno-exceptions -funwind-tables -fasynchronous-unwind-tables -fno-rtti -DTARGET_IA32E -DHOST_IA32E -fPIC -DTARGET_LINUX -fabi-version=2 -I/home/siavash/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/source/include/pin -I/home/siavash/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/source/include/pin/gen -isystem /home/siavash/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/extras/stlport/include -isystem /home/siavash/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/extras/libstdc++/include -isystem /home/siavash/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/extras/crt/include -isystem /home/siavash/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/extras/crt/include/arch-x86_64 -isystem /home/siavash/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/extras/crt/include/kernel/uapi -isystem /home/siavash/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/extras/crt/include/kernel/uapi/asm-x86 -I/home/siavash/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/extras/components/include -I/home/siavash/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/extras/xed-intel64/include/xed -I/home/siavash/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/source/tools/InstLib -O3 -fomit-frame-pointer -fno-strict-aliasing -I/home/siavash/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/extras/pinplay//include -std=c++14 -c -o obj-intel64/gen_trace.o gen_trace.cc -MD -DPIN_COMPILE gen_trace.cc:62:10: fatal error: globals/assert.h: No such file or directory
#include "globals/assert.h"
^~~~~~~~~~~~~~~~~~
compilation terminated.
makefile.rules:97: recipe for target 'obj-intel64/gen_trace.o' failed
make[1]: *** [obj-intel64/gen_trace.o] Error 1
make[1]: Leaving directory '/home/siavash/scarab/src/pin/pin_trace'
/home/siavash/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/source/tools/Config/makefile.config:328: recipe for target 'all' failed
make: *** [all] Error 2

Expected behavior
Compiles without errors

Desktop :

• OS: Ubuntu 18.04 in WSL
• Compiler: gcc 7.5.0

Describe the bug
Compilation fails on Makefile line 253: pin_fe_lib_opt

To Reproduce
Steps to reproduce the behavior:

1. cd src && make

Building 'dep/Linux/opt/bp/gshare.dd'
Building 'dep/Linux/opt/bp/hybridgp.dd'
Building 'dep/Linux/opt/bp/tagescl.dd'
Building 'dep/Linux/opt/power/power_scarab_config.dd'
Building 'dep/Linux/opt/frontend/pin_trace_read.dd'
Building 'dep/Linux/opt/frontend/pin_exec_driven_fe.dd'
Building 'dep/Linux/opt/ramulator.dd'
Building 'dep/Linux/opt/bp/bp_conf.d, bp/bp_conf'
Building 'dep/Linux/opt/bp/bp.d, bp/bp'
Building 'dep/Linux/opt/bp/bp_targ_mech.d, bp/bp_targ_mech'
Building 'dep/Linux/opt/prefetcher/pref_stridepc.d, prefetcher/pref_stridepc'
Building 'dep/Linux/opt/prefetcher/pref_stream.d, prefetcher/pref_stream'
Building 'dep/Linux/opt/prefetcher/l2way_pref.d, prefetcher/l2way_pref'
Building 'dep/Linux/opt/prefetcher/pref_stride.d, prefetcher/pref_stride'
Building 'dep/Linux/opt/prefetcher/pref_phase.d, prefetcher/pref_phase'
Building 'dep/Linux/opt/prefetcher/pref_markov.d, prefetcher/pref_markov'
Building 'dep/Linux/opt/prefetcher/pref_ghb.d, prefetcher/pref_ghb'
Building 'dep/Linux/opt/prefetcher/l2markv_pref.d, prefetcher/l2markv_pref'
Building 'dep/Linux/opt/prefetcher/l2l1pref.d, prefetcher/l2l1pref'
Building 'dep/Linux/opt/prefetcher/pref_2dc.d, prefetcher/pref_2dc'
Building 'dep/Linux/opt/prefetcher/pref_common.d, prefetcher/pref_common'
Building 'dep/Linux/opt/prefetcher/stream_pref.d, prefetcher/stream_pref'
Building 'dep/Linux/opt/dvfs/dvfs.d, dvfs/dvfs'
Building 'dep/Linux/opt/dvfs/perf_pred.d, dvfs/perf_pred'
Building 'dep/Linux/opt/dvfs/power_pred.d, dvfs/power_pred'
Building 'dep/Linux/opt/power/power_intf.d, power/power_intf'
Building 'dep/Linux/opt/debug/pipeview.d, debug/pipeview'
Building 'dep/Linux/opt/debug/debug_print.d, debug/debug_print'
Building 'dep/Linux/opt/debug/memview.d, debug/memview'
Building 'dep/Linux/opt/frontend/frontend_intf.d, frontend/frontend_intf'
Building 'dep/Linux/opt/frontend/frontend.d, frontend/frontend'
Building 'dep/Linux/opt/frontend/pin_trace_fe.d, frontend/pin_trace_fe'
Building 'dep/Linux/opt/libs/cache_lib.d, libs/cache_lib'
Building 'dep/Linux/opt/libs/malloc_lib.d, libs/malloc_lib'
Building 'dep/Linux/opt/libs/hash_lib.d, libs/hash_lib'
Building 'dep/Linux/opt/libs/port_lib.d, libs/port_lib'
Building 'dep/Linux/opt/libs/list_lib.d, libs/list_lib'
Building 'dep/Linux/opt/isa/isa.d, isa/isa'
Building 'dep/Linux/opt/globals/utils.d, globals/utils'
Building 'dep/Linux/opt/globals/enum.d, globals/enum'
Building 'dep/Linux/opt/cache_part.d, cache_part'
Building 'dep/Linux/opt/dcache_stage.d, dcache_stage'
Building 'dep/Linux/opt/stat_trace.d, stat_trace'
Building 'dep/Linux/opt/thread.d, thread'
Building 'dep/Linux/opt/trigger.d, trigger'
Building 'dep/Linux/opt/map.d, map'
Building 'dep/Linux/opt/exec_stage.d, exec_stage'
Building 'dep/Linux/opt/memory.d, memory'
Building 'dep/Linux/opt/cmp_model.d, cmp_model'
Building 'dep/Linux/opt/op_pool.d, op_pool'
Building 'dep/Linux/opt/node_stage.d, node_stage'
[ -f gitrev ] || touch gitrev
echo '"'c23ee41'"' | cmp -s gitrev - || echo '"'c23ee41'"' > gitrev
Building 'dep/Linux/opt/version.d, version'
Building 'dep/Linux/opt/map_stage.d, map_stage'
Building 'dep/Linux/opt/dumb_model.d, dumb_model'
Building 'dep/Linux/opt/optimizer2.d, optimizer2'
Building 'dep/Linux/opt/addr_trans.d, addr_trans'
Building 'dep/Linux/opt/statistics.d, statistics'
Building 'dep/Linux/opt/exec_ports.d, exec_ports'
Building 'dep/Linux/opt/icache_stage.d, icache_stage'
Building 'dep/Linux/opt/decode_stage.d, decode_stage'
Building 'dep/Linux/opt/main.d, main'
Building 'dep/Linux/opt/cmp_model_support.d, cmp_model_support'
Building 'dep/Linux/opt/packet_build.d, packet_build'
Building 'dep/Linux/opt/param_parser.d, param_parser'
Building 'dep/Linux/opt/sim.d, sim'
Building 'dep/Linux/opt/freq.d, freq'
Building 'dep/Linux/opt/mem_req.d, mem_req'
Building 'dep/Linux/opt/stat_mon.d, stat_mon'
[ -f gitrev ] || touch gitrev
echo '"'c23ee41'"' | cmp -s gitrev - || echo '"'c23ee41'"' > gitrev
make SCARAB_DIR=/magnetic/src/scarab/src --directory pin/pin_lib
make[1]: Entering directory '/magnetic/src/scarab/src/pin/pin_lib'
make dir
make[2]: Entering directory '/magnetic/src/scarab/src/pin/pin_lib'
mkdir -p obj
make[2]: Leaving directory '/magnetic/src/scarab/src/pin/pin_lib'
make archive
make[2]: Entering directory '/magnetic/src/scarab/src/pin/pin_lib'
g++ -MT obj/message_queue_interface_lib.o -MMD -MP -MF obj/message_queue_interface_lib.d -std=c++14 -O3 -fno-inline -funroll-loops -Werror -I/magnetic/src/scarab/src -DNO_DEBUG -Wall -Wunused -Wno-long-long -Wpointer-arith -Werror -D_REENTRANT -fPIC -c -o obj/message_queue_interface_lib.o message_queue_interface_lib.cc
g++ -MT obj/pin_scarab_common_lib.o -MMD -MP -MF obj/pin_scarab_common_lib.d -std=c++14 -O3 -fno-inline -funroll-loops -Werror -I/magnetic/src/scarab/src -DNO_DEBUG -Wall -Wunused -Wno-long-long -Wpointer-arith -Werror -D_REENTRANT -fPIC -c -o obj/pin_scarab_common_lib.o pin_scarab_common_lib.cc
gcc -MT obj/uop_generator.o -MMD -MP -MF obj/uop_generator.d -std=gnu99 -O3 -funroll-loops -Werror -I/magnetic/src/scarab/src -DNO_DEBUG -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wno-long-long -Wpointer-arith -Wimplicit -Werror -D_REENTRANT -fPIC -c -o obj/uop_generator.o uop_generator.c
ar rcs obj/libpin_fe.a obj/message_queue_interface_lib.o obj/pin_scarab_common_lib.o obj/uop_generator.o
make[2]: Leaving directory '/magnetic/src/scarab/src/pin/pin_lib'
make[1]: Leaving directory '/magnetic/src/scarab/src/pin/pin_lib'
make SCARAB_DIR=/magnetic/src/scarab/src rollback --directory pin/pin_exec
make[1]: Entering directory '/magnetic/src/scarab/src/pin/pin_exec'
makefile:13: ../Config/makefile.config: No such file or directory
makefile:15: /Config/makefile.default.rules: No such file or directory
make[1]: *** No rule to make target '/Config/makefile.default.rules'. Stop.
make[1]: Leaving directory '/magnetic/src/scarab/src/pin/pin_exec'
Makefile:253: recipe for target 'pin_fe_lib_opt' failed
make: *** [pin_fe_lib_opt] Error 2

Expected behavior
Expected to compile succesfully

Desktop (please complete the following information):

• OS: Ubuntu 18.04.4 LTS (Bionic Beaver)

Describe the bug

The project does not compile due to multiple errors.

1. File src/ramulator/StatType.h is missing #include <stdint.h> or at least #include <cstdint> to use the types uint3264_t et al. (The difference between both headers is that the last one, per the standard, includes the names under the namespace std::, which is not used in the codebase for these names.)
2. The project compiles with -Werror, specified in src/CmakeLists.txt and taken as a flag from the PIN3.5 dependency and in newer versions of GCC the project has some warnings, like the following.

../pin_lib/decoder.cc: In function ‘void pin_decoder_print_unknown_opcodes()’:
../pin_lib/decoder.cc:140:18: error: loop variable ‘opcode’ creates a copy from type ‘const std::basic_string<char, std::char_traits<char>, std::allocator<char> >’ [-Werror=range-loop-construct]
  140 |   for(const auto opcode : unknown_opcodes) {
      |                  ^~~~~~
../pin_lib/decoder.cc:140:18: note: use reference type to prevent copying
  140 |   for(const auto opcode : unknown_opcodes) {
      |                  ^~~~~~
      |                  &
cc1plus: all warnings being treated as errors

3. There are shared global variable names that are not declared static nor extern, leading to link errors. For example, variable proc_infos is declared in multiple files. It is not clear whether these variables should point to the same memory (and be change to extern) or not (static).

src $ grep -R -E '\bProc_Info\*\s*proc_infos'
dvfs/dvfs.c:static Proc_Info* proc_infos;
dvfs/perf_pred.c:Proc_Info* proc_infos;
memory/cache_part.c:Proc_Info* proc_infos;
debug/memview.c:Proc_Info*    proc_infos;

To Reproduce

I'm compiling with the following software:

• CMake 3.28.3
• GNU Make 4.4.1
• GCC 13.2.1
• OS: Arch Linux

Scarab does not support an ICACHE_CYCLES latency. Should we use EXTRA_REDIRECT_CYCLES for this or is the latency of the icache exposed in the case of a redirect modelled somewhere else already?

Hello folks,

my name is Surim who is a Ph.D. student at UCSC advised by Prof. Litz. I have been using Scarab for our research. On top of Scarab, I am working on the Fetch-Directed Instruction Prefetching (FDIP) mechanism to improve the frontend-bound applications. In our FDIP implementation, when it emits a prefetch for an instruction cache line, we call new_mem_req() function with a newly added MRT_FDIPPRF type. We have added logic for merging requests based on the priority of IFETCH and FDIPPRF types. I would like to ask some questions about the memory implementation. Could any of you answer the following questions if you have any chance to have a look?

1. I can see there are queues with 7 different types and a single req_buffer for each core shared by all the different types of queues. The buffer has a fixed size MEM_REQ_BUFFER_ENTRIES when PRIVATE_MSHR_ON is off. Can you briefly explain why the implementation separates the buffer and queues instead of just using the buffer only? Is it to handle the different priorities of memory requests? Also, I would appreciate it if you could briefly explain when and how requests move between queues.

2. I think that at first, it was intended to implement QUEUE_MEM and to enqueue a request when it is sent to the memory. Currently, the ‘queue’ pointer of a request becomes NULL when the request is sent to ramulator, and the request becomes undiscoverable in any of the queues. I think there exists a period when we cannot find a matching request even though the request is in process. We expect that all the requests to the same cache line address will be merged into the first request in all periods of time until the first request is processed and the cache line is actually loaded into the cache. If we lose some merging opportunities, it will lead to unnecessarily additional waste of memory bandwidth for the same cache line. I quickly checked IPC gains by finding a valid memory request directly from the whole req_buffer and merging it directly into the buffer instead of finding one from the queues. I can see IPC gains in all the benchmarks I used. Do you think we can just directly use the buffer during the merging process instead of the queues?

3. Also, in mem_search_queue, when it finds a matching request, it only finds the request which is not in the final state (MRS_MLC_HIT_DONE, MRS_L1_HIT_DONE, MRS_MEM_DONE, MRS_FILL_DONE). Could you tell me the reason why it excludes these final states from the merging candidates?

Best,
Surim

We are graduate students from the Dept of EECS, Pennsylvania State University and we are new to using the scarab simulator available on GitHub. We are trying to use the tool in debug mode. Is it enough for us to just do a make with the debug flag and run the tool as normal with the binary or are we supposed to enable a debug flag as like in gem5 while running as part of the command. Kindly guide us for running the tool in debug mode.

[Question posted on behalf of someone else]

Hello,

I am a PhD student working with Prof. Anand Sivasubramaniam at Penn State. I was trying to simulate benchmarks in SPEC2017 Integer Speed by first generating checkpoints according to docs/run_spec17.md and then running the checkpoints with "python3 bin/scarab_batch.py </path/to/scarab_batch_profile.py> --run". The config file I used is src/PARAMS.kaby_lake.

All benchmarks except for gcc were simulated successfully. For gcc, I encountered error messages saying that "thread.c:86: ASSERT FAILED (P=0 O=42250155 I=32048837 C=23808191): Scarab's recovery addr 0x573b3a does not match frontend's recovery addr 0xbba910" for <ref1, ckpt4> and "thread.c:86: ASSERT FAILED (P=0 O=259514256 I=198999152 C=143214723): Scarab's recovery addr 0x573b54 does not match frontend's recovery addr 0xbba910" for <ref2, ckpt2>.

Gcc was simulated successfully with "--fetch_off_path_ops 0" though. Could you please take a look at this problem? Thanks a lot!

Best,
Yunjin

What does Scarab's wrong path execution mean? Only wrong path instruction fetch or actual wrong path execution which (for example) affects Dcache?

(at least in trace mode) if I disable ENABLE_ICACHE_PACKET_BREAKING and also disable the perfect branch predictor, running scarab fails with ic->next_fetch_addr == op->inst_info->addr

Looking into packet_build.c I see:

if(ENABLE_ICACHE_PACKET_BREAKING) {
  // control flow instruction
  if(op->table_info->cf_type)
    return PB_BREAK_AFTER;
}

If I understand correctly if ENABLE_ICACHE_PACKET_BREAKING is enabled, scarab breaks after every CF instruction (no modern architecture breaks after correctly predicted non-taken branches so I want to disable it).

Now, with ENABLE_ICACHE_PACKET_BREAKING disabled, when the first branch is mispredicted the instruction after the branch is incorrect as, I assume, the icache_stage/packet_build reads an instruction from the trace that does not match the predicted instructions PC. The problem is that packet_build happens before branch prediction and so during packet build, we do not know whether we are staying on the ON_PATH or going OFF_PATH. It seems that the next instruction after the branch is determined before the branch is predicted. If we knew that the CF is going to be mispredicted we could break only in this case but currently, it breaks after each CF even after those that are correctly predicted.

I believe this problem should also cause issues for exec_driven mode as the PIN-frontend can only be re-steered if a branch misprediction is detected.

Let me know if I am missing sth and if you have an idea to solve this problem (not breaking after each CF without perfect branch predictor)

How do you write a prefetcher in Scarab? What components/functions do you need and how do you integrate them? I've been trying to understand the stream prefetcher in particular. What do the pref_stream_throttle, pref_stream_ul1_miss, and pref_stream_train_stream_filter method do?

[question posted on behalf of someone else]

An entry is added to the BTB on a not taken branch. Later, when a branch is taken the BTB entry is not updated. Is there a reason for this behavior or is this a bug?

You can see this behavior by stepping through the code following any branch.
Looking at the most recent commit in the master branch:
Updating the BTB only happens in bp.c:610 when the op is tagged as a BTB miss.
However, an op is tagged as a BTB miss at bp.c:347 in bp_target_known_op() if the BTB does not have an entry for the branch, regardless of whether the branch was taken/not taken or predicted correctly/incorrectly.

This causes many BTB misses to be incorrectly labeled as misfetches. For example, a direct conditional branch should never miss in the BTB since only the target on the taken path should be stored.

I am running a workload on the memtrace branch but the code in question is identical on the master.
Thanks!

When I run make -C docs, I get an error that says docs/qsort-example-docs/contents.rst not found. Any advice how to fix this would be helpful.

pwintz-2-in-1:~/code/scarab
$ make -C docs
make: Entering directory '/home/pwintz/code/scarab/docs'
make docs -C ../src
make html -C qsort-example-docs
make[1]: Entering directory '/home/pwintz/code/scarab/docs'
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Entering directory '/home/pwintz/code/scarab/docs'
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: *** No rule to make target 'docs'.  Stop.
make[1]: Leaving directory '/home/pwintz/code/scarab/src'
make: *** [Makefile:8: scarab-src] Error 2
make: *** Waiting for unfinished jobs....
Running Sphinx v1.8.5
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 1 source files that are out of date
updating environment: 1 added, 0 changed, 0 removed
reading sources... [100%] index

Sphinx error:
master file /home/pwintz/code/scarab/docs/qsort-example-docs/contents.rst not found
make[1]: *** [Makefile:23: html] Error 2
make[1]: Leaving directory '/home/pwintz/code/scarab/docs/qsort-example-docs'
make: *** [Makefile:11: qsort-example] Error 2
make: Leaving directory '/home/pwintz/code/scarab/docs'

When scarab runs clang 10, scarab fails the assertion:

icache_stage.c:479: ASSERT FAILED (P=0  O=29044870  I=23546173  C=18330112):  ic->next_fetch_addr == op->inst_info->addr
icache_stage.c:479: ASSERT FAILED (P=0  O=29044870  I=23546173  C=18330112):  Fetch address 0x7fffe2e0de97 does not match op address 0x7fffe2e4aa31
Obtained 7 stack frames.
/home/nlbrow/scarab/src/scarab(+0xac17f) [0x55d536f2917f]
/home/nlbrow/scarab/src/scarab(update_icache_stage+0x2e6) [0x55d536f2b026]
/home/nlbrow/scarab/src/scarab(cmp_cycle+0x31d) [0x55d536f4978d]
/home/nlbrow/scarab/src/scarab(full_sim+0x178) [0x55d536f16438]
/home/nlbrow/scarab/src/scarab(main+0x197) [0x55d536f0ca47]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f487a82eb97]
/home/nlbrow/scarab/src/scarab(_start+0x2a) [0x55d536f1049a]
../pin_lib/message_queue_interface_lib.cc:161 (Client)$ Socket closed unexpectedly on read. Scarab process probably died.: Success

To Reproduce
Steps to reproduce the behavior:

1. Go to LLVM Downloads and get the binaries for clang 10.0.0
2. Generate hello.c with the simple contents of:

#include <stdio.h>

int main() {
        printf("Hello world!");
}

3. Run scarab with the default PARAM file:
   ./bin/scarab_launch.py --program "$CLANG hello.c" --param src/PARAMS.*, where CLANG is set to the downloaded binary from (1). There are no other PARAMS files under src beyond the provided kaby_lake parameters.
4. The full error output is:

Launching Scarab:
/home/nlbrow/scarab/src/scarab --num_cores 1 --pin_exec_driven_fe_socket /tmp/Scarab_Temp_WorkDir_hkzcuag8/socket --bindir /home/nlbrow/scarab/bin

Scarab gitrev: fd25a51
Listening for new clients
accepting for new clients

Core 0 is running program: /home/nlbrow/clang+llvm-10.0.0-x86_64-linux-gnu-ubuntu-18.04/bin/clang hello.c
setarch x86_64 -R /home/nlbrow/pinplay-drdebug-3.5-pin-3.5-97503-gac534ca30-gcc-linux/pin -mt 0 -t /home/nlbrow/scarab/src/pin/pin_exec/obj-intel64/pin_exec.so -socket_path /tmp/Scarab_Temp_WorkDir_hkzcuag8/socket -core_id 0  -- /home/nlbrow/clang+llvm-10.0.0-x86_64-linux-gnu-ubuntu-18.04/bin/clang hello.c

Server verified connection.
Client verified connection.
Scarab started at Wed Sep  9 00:00:07 2020

Initialized Ramulator.
Exiting Fast Forward mode: inst_count=2
** Heartbeat:   0% -- { 1000001 } -- 0.00 KIPS (76.92 KIPS)
** Heartbeat:   0% -- { 2000006 } -- 250.00 KIPS (117.65 KIPS)
** Heartbeat:   0% -- { 3000006 } -- 142.86 KIPS (125.00 KIPS)
** Heartbeat:   0% -- { 4000006 } -- 43.48 KIPS (85.11 KIPS)
** Heartbeat:   0% -- { 5000007 } -- 52.63 KIPS (75.76 KIPS)
** Heartbeat:   0% -- { 6000010 } -- 166.67 KIPS (83.33 KIPS)
** Heartbeat:   0% -- { 7000012 } -- 200.00 KIPS (90.91 KIPS)
** Heartbeat:   0% -- { 8000015 } -- 250.00 KIPS (98.77 KIPS)
** Heartbeat:   0% -- { 9000018 } -- 55.56 KIPS (90.91 KIPS)

icache_stage.c:479: ASSERT FAILED (P=0  O=12313942  I=9414238  C=6992373):  ic->next_fetch_addr == op->inst_info->addr
icache_stage.c:479: ASSERT FAILED (P=0  O=12313942  I=9414238  C=6992373):  Fetch address 0x7fffe2b65e97 does not match op address 0x7fffe2ba2a31
Obtained 7 stack frames.
/home/nlbrow/scarab/src/scarab(+0xac17f) [0x55af5540417f]
/home/nlbrow/scarab/src/scarab(update_icache_stage+0x2e6) [0x55af55406026]
/home/nlbrow/scarab/src/scarab(cmp_cycle+0x31d) [0x55af5542478d]
/home/nlbrow/scarab/src/scarab(full_sim+0x178) [0x55af553f1438]
/home/nlbrow/scarab/src/scarab(main+0x197) [0x55af553e7a47]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7fdd67d56b97]
/home/nlbrow/scarab/src/scarab(_start+0x2a) [0x55af553eb49a]
../pin_lib/message_queue_interface_lib.cc:161 (Client)$ Socket closed unexpectedly on read. Scarab process probably died.: Success
RETURN CODE 15: /home/nlbrow/scarab/src/scarab --num_cores 1 --pin_exec_driven_fe_socket /tmp/Scarab_Temp_WorkDir_hkzcuag8/socket --bindir /home/nlbrow/scarab/bin

Error: TERMINATING BECAUSE NON-ZERO RETURN CODE FOR:
/home/nlbrow/scarab/src/scarab --num_cores 1 --pin_exec_driven_fe_socket /tmp/Scarab_Temp_WorkDir_hkzcuag8/socket --bindir /home/nlbrow/scarab/bin

Notify: Scarab run terminated, cleaning up...

Expected behavior
I instead expect scarab to not fail the assertion. When I comment the assertion out, scarab does not fail, and clang correctly compiles the executable.

Desktop (please complete the following information):

• OS: Ubuntu Bionic Beaver
• Version: current HEAD: fd25a51

Additional context
When the assertion is commented out, everything works just fine.

Hi, I'm trying to build scarab on my ubuntu machine and am facing the following error

root@system-performance-lab:~/performance-analysis/scarab/src# make
make SCARAB_DIR=/root/performance-analysis/scarab/src pin_exec --directory pin/pin_exec	 --no-print-directory
invoking link
g++ -shared -Wl,--hash-style=sysv /root/performance-analysis/pin-3.15-98253-gb56e429b1-gcc-linux//intel64/runtime/pincrt/crtbeginS.o -Wl,-Bsymbolic -Wl,--version-script=/root/performance-analysis/pin-3.15-98253-gb56e429b1-gcc-linux//source/include/pin/pintool.ver -fabi-version=2   -std=c++14 -o obj-intel64/pin_exec.so obj-intel64/pin_exec.o obj-intel64/analysis_functions.o obj-intel64/globals.o obj-intel64/main_loop.o obj-intel64/exception_handling.o obj-intel64/scarab_interface.o obj-intel64/decoder.o obj-intel64/gather_scatter_addresses.o obj-intel64/message_queue_interface_lib.o obj-intel64/pin_scarab_common_lib.o obj-intel64/x86_decoder.o obj-intel64/x87_stack_delta.o -L/root/performance-analysis/pin-3.15-98253-gb56e429b1-gcc-linux//intel64/runtime/pincrt -L/root/performance-analysis/pin-3.15-98253-gb56e429b1-gcc-linux//intel64/lib -L/root/performance-analysis/pin-3.15-98253-gb56e429b1-gcc-linux//intel64/lib-ext -L/root/performance-analysis/pin-3.15-98253-gb56e429b1-gcc-linux//extras/xed-intel64/lib -lpin -lxed /root/performance-analysis/pin-3.15-98253-gb56e429b1-gcc-linux//intel64/runtime/pincrt/crtendS.o -lpin3dwarf -ldl-dynamic -nostdlib -lstlport-dynamic -lm-dynamic -lc-dynamic -lunwind-dynamic
/usr/bin/ld: warning: util_host_ia32e.os: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
mkdir -p build/opt/
echo gcc
gcc
echo g++
g++
cd build/opt/; \
  CC=gcc      \
  CXX=g++     \
   ../.. -DCMAKE_BUILD_TYPE=ScarabOpt
/bin/sh: 2: ../..: Permission denied
make: *** [Makefile:89: build/opt/Makefile] Error 126

Its not giving me any detailed error. I'm using Intel Pin 3.15

Please let me know where I'm going now or what's missing here

Is there a way to print out the stats in a machine-readable format?
Do you have stats parsers for the output files that you could share?

Also, it seems as if rows 2 and 3 in the stats files are duplicated as rows 4 and 5. What is the reason behind this?

thanks, Heiner

I've been trying to setup Sacrab on a Windows Linux Subsystem (Ubuntu). I've installed g++, gcc, Clang, and Python 3 using
sudo apt install clang g++ gcc python3.

The versions that apt installed are

• gcc 9.4.0
• g++ 9.3.0
• clang 10.0.0
• Python 3.8.10

I was hoping that having newer versions of the dependencies would be OK, but when I run make in the src directory, I get an error that says, ‘setprecision’ was not declared in this scope. Is this a dependency problem or something else?

pwintz-2-in-1:~/code/scarab/src
$ make
make SCARAB_DIR=/home/pwintz/code/scarab/src pin_exec --directory pin/pin_exec   --no-print-directory
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
mkdir -p build/opt/
echo gcc
gcc
echo g++
g++
cd build/opt/; \
  CC=gcc      \
  CXX=g++     \
   ../.. -DCMAKE_BUILD_TYPE=ScarabOpt
/bin/sh: 2: ../..: Permission denied
make: *** [Makefile:89: build/opt/Makefile] Error 126
make: *** Waiting for unfinished jobs....
g++ -DBIGARRAY_MULTIPLIER=1 -Wall -Werror -Wno-unknown-pragmas -D__PIN__=1 -DPIN_CRT=1 -fno-stack-protector -fno-exceptions -funwind-tables -fasynchronous-unwind-tables -fno-rtti -DTARGET_IA32E -DHOST_IA32E -fPIC -DTARGET_LINUX -fabi-version=2  -I/home/pwintz/code/scarab/pins/PIN-Play_3.5/source/include/pin -I/home/pwintz/code/scarab/pins/PIN-Play_3.5/source/include/pin/gen -isystem /home/pwintz/code/scarab/pins/PIN-Play_3.5/extras/stlport/include -isystem /home/pwintz/code/scarab/pins/PIN-Play_3.5/extras/libstdc++/include -isystem /home/pwintz/code/scarab/pins/PIN-Play_3.5/extras/crt/include -isystem /home/pwintz/code/scarab/pins/PIN-Play_3.5/extras/crt/include/arch-x86_64 -isystem /home/pwintz/code/scarab/pins/PIN-Play_3.5/extras/crt/include/kernel/uapi -isystem /home/pwintz/code/scarab/pins/PIN-Play_3.5/extras/crt/include/kernel/uapi/asm-x86 -I/home/pwintz/code/scarab/pins/PIN-Play_3.5/extras/components/include -I/home/pwintz/code/scarab/pins/PIN-Play_3.5/extras/xed-intel64/include -I/home/pwintz/code/scarab/pins/PIN-Play_3.5/source/tools/InstLib -O3 -fomit-frame-pointer -fno-strict-aliasing  -std=c++14 -g3 -static -I/home/pwintz/code/scarab/src -Wno-error=deprecated-declarations  -c -o obj-intel64/analysis_functions.o analysis_functions.cc -DPIN_COMPILE
analysis_functions.cc: In function ‘void docount(UINT32)’:
analysis_functions.cc:39:13: error: ‘setprecision’ was not declared in this scope
   39 |          << setprecision(2)
      |             ^~~~~~~~~~~~
make[1]: *** [makefile.rules:97: obj-intel64/analysis_functions.o] Error 1
make: *** [Makefile:38: pin_exec] Error 2

The following code in packet_build.c line 247 forces a packet break after each CF instruction

if(ENABLE_ICACHE_PACKET_BREAKING) {
  // control flow instruction
  if(op->table_info->cf_type)
    return PB_BREAK_AFTER;
}

while line 219 forces a packet break if the number of CF instructions exceeds CFS_PER_CYCLE

  pb_data->break_conditions[NUM_CF] += (op->table_info->cf_type != 0);
  if(pb_data->break_conditions[NUM_CF] == CFS_PER_CYCLE) {
    *break_fetch = BREAK_CF;
    return PB_BREAK_AFTER;
  }

Q1: Doesn't line 247 make line 219 obsolete?
Q2: Why isnt' the *break_fetch reason set in line 247?

I commented out line 247 to enable instruction decoding after a CF instruction, but then the following assertion failed.
icache_stage.c:476: ASSERT FAILED (P=0 O=125 I=86 C=1350): ic->next_fetch_addr == op->inst_info->addr

I traced back the code and "ic->next_fetch_addr" is set by "bp_predict_op" in line 572.

Q3: Branch prediction can be wrong so isn't it natural that this assertion fails?
Q4: With fetch break on each CF instruction, the assertion in contrast never fails? Why?
Q5: Is it save to just comment out the assertion above?

thanks a lot in advance!

Hello,

If I wanted to run scarab on traces not from Pin or of the ctype_pin_inst format, such as the traces from CBP, would scarab support those? From what I can tell, the current frontend infrastructure is highly dependent on the ctype_pin_inst format, whose fields like size, is_* and pin_iclass suggest a strong need to have the traces come with some kind of information on opcode / instruction bytes. Does scarab support running traces without such rich information? If so, how might one go about making that happen?

This link has some helpful information to fix this:
actions/checkout#298

Hello!

I wanted to ask if I can get some documentation or anything else to find out how I can run the SPEC 17 application. I have already generated the checkpoints and the descriptor.def but can't find a way to run them on scarab.

Sawan

Does Scarab have support for runahead execution? I saw the cmp_model files that were described as "CMP with runahead", but I'm not sure if that was it and if so, how to enable it and use it in a simulation.

When writing a prefetcher, is there a way to specify which cache level to prefetch into? If so, how?

Describe the bug
Changing the size of the buffer between PIN/Scarab (by changing the knob KnobMaxBufferSize in the pin_exec pintool) changes the resulting IPC (and other stats). I am filing this as a bug because we currently do not understand why this happens.

To Reproduce
Steps to reproduce the behavior:

1. checkout commit c5b1845
2. run and collect stats, both with KnobMaxBufferSize set to 32, and with KnobMaxBufferSize set to 8, on spec 2017 chckpoints. The exact configuration you run with shouldn't matter, except that wrong path should be enabled (as I suspect the issue is related to wrong path ops)
3. observe the difference in stats produced. Not all of my Spec 2017 checkpoints see a difference, but most do. The IPC different is usually quite small (<0.1%), but non-zero

Expected behavior
We currently expect the exact same IPC, given that all other configurations are the same except the buffer size.

I have been setting up Scarab in Ubuntu 22.04.1 LTS, and I cannot seem to compile Scarab properly. I have properly installed all the dependencies and followed the instructions for compiling Scarab. However, I consistently encounter an error regarding the use of the submodule DynamoRIO. Is there something that I am missing in using Scarab with DynamoRIO? I am currently using glibc 2.35.

[ 38%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/arch/clean_call_opt_shared.c.o
Warning: Treating `dword ptr [96]' as memory reference
/home/arcak-lab/scarab/src/deps/dynamorio/core/arch/x86/x86.asm:2520: Warning: Treating `qword ptr [88]' as memory reference
/home/arcak-lab/scarab/src/deps/dynamorio/core/arch/x86/x86.asm:2533: Warning: Treating `qword ptr [16]' as memory reference
[ 38%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/pcprofile.c.o
[ 38%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/stackdump.c.o
[ 38%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/arch/x86_code.c.o
[ 39%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/diagnost.c.o
[ 39%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/arch/x86/optimize.c.o
[ 39%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/loader.c.o
[ 39%] Building ASM object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/arch/x86/x86.asm.o
[ 39%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/loader_linux.c.o
[ 39%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/memquery_linux.c.o
[ 40%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/memquery.c.o
[ 39%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/arch/sideline.c.o
[ 40%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/arch/retcheck.c.o
[ 40%] Built target drfrontendlib
[ 40%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/memcache.c.o
[ 40%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/module.c.o
[ 40%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/signal.c.o
[ 40%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/arch/x86/x86_to_x64.c.o
[ 40%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/os.c.o
[ 41%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/module_elf.c.o
[ 41%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/pcprofile.c.o
[ 41%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/ksynch_linux.c.o
/home/arcak-lab/scarab/src/deps/dynamorio/core/arch/x86/x86.asm: Assembler messages:
/home/arcak-lab/scarab/src/deps/dynamorio/core/arch/x86/x86.asm:2507: Warning: Treating `dword ptr [96]' as memory reference
/home/arcak-lab/scarab/src/deps/dynamorio/core/arch/x86/x86.asm:2520: Warning: Treating `qword ptr [88]' as memory reference
/home/arcak-lab/scarab/src/deps/dynamorio/core/arch/x86/x86.asm:2533: Warning: Treating `qword ptr [16]' as memory reference
[ 41%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/tls_linux_x86.c.o
[ 41%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/signal_linux.c.o
[ 41%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/signal_linux_x86.c.o
[ 41%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/stackdump.c.o
[ 41%] Building CXX object deps/dynamorio/clients/drcachesim/CMakeFiles/directory_iterator.dir/common/directory_iterator.cpp.o
[ 41%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/loader.c.o
[ 41%] Building C object deps/dynamorio/libutil/CMakeFiles/drconfiglib.dir/dr_config.c.o
[ 42%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/diagnost.c.o
[ 42%] Building C object deps/dynamorio/libutil/CMakeFiles/drconfiglib.dir/utils.c.o
[ 42%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/loader_linux.c.o
[ 42%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/memquery_linux.c.o
[ 42%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/native_elf.c.o
[ 43%] Building C object deps/dynamorio/libutil/CMakeFiles/drconfiglib.dir/__/core/io.c.o
[ 43%] Building C object deps/dynamorio/libutil/CMakeFiles/drconfiglib.dir/__/core/unix/nudgesig.c.o
[ 44%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/nudgesig.c.o
[ 44%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/memquery.c.o
[ 44%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/rseq_linux.c.o
[ 44%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/memcache.c.o
[ 44%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/tls_linux_x86.c.o
[ 45%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/module_elf.c.o
[ 45%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/signal_linux_x86.c.o
[ 45%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/signal_linux.c.o
[ 45%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/ksynch_linux.c.o
[ 45%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/native_elf.c.o
[ 46%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/nudgesig.c.o
[ 46%] Building C object deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/rseq_linux.c.o
/home/arcak-lab/scarab/src/deps/dynamorio/core/unix/rseq_linux.c: In function ‘rseq_clear_tls_ptr’:
/home/arcak-lab/scarab/src/deps/dynamorio/core/unix/rseq_linux.c:221:64: error: request for member ‘ptr64’ in something not a structure or union
  221 |     if (is_dynamo_address((byte *)(ptr_uint_t)app_rseq->rseq_cs.ptr64))
      |                                                                ^
/home/arcak-lab/scarab/src/deps/dynamorio/core/unix/rseq_linux.c:222:26: error: request for member ‘ptr64’ in something not a structure or union
  222 |         app_rseq->rseq_cs.ptr64 = 0;
      |                          ^
make[3]: *** [deps/dynamorio/core/CMakeFiles/dynamorio.dir/build.make:1214: deps/dynamorio/core/CMakeFiles/dynamorio.dir/unix/rseq_linux.c.o] Error 1
make[3]: *** Waiting for unfinished jobs....
/home/arcak-lab/scarab/src/deps/dynamorio/core/unix/rseq_linux.c: In function ‘rseq_clear_tls_ptr’:
/home/arcak-lab/scarab/src/deps/dynamorio/core/unix/rseq_linux.c:221:64: error: request for member ‘ptr64’ in something not a structure or union
  221 |     if (is_dynamo_address((byte *)(ptr_uint_t)app_rseq->rseq_cs.ptr64))
      |                                                                ^
/home/arcak-lab/scarab/src/deps/dynamorio/core/unix/rseq_linux.c:222:26: error: request for member ‘ptr64’ in something not a structure or union
  222 |         app_rseq->rseq_cs.ptr64 = 0;
      |                          ^
make[3]: *** [deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/build.make:1214: deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/unix/rseq_linux.c.o] Error 1
make[3]: *** Waiting for unfinished jobs....
[ 46%] Linking CXX static library ../lib64/release/libdirectory_iterator.a
[ 46%] Built target directory_iterator
[ 46%] Building CXX object deps/dynamorio/clients/drcachesim/CMakeFiles/drmemtrace_analyzer.dir/common/trace_entry.cpp.o
[ 46%] Building CXX object deps/dynamorio/clients/drcachesim/CMakeFiles/drmemtrace_analyzer.dir/analyzer.cpp.o
[ 47%] Linking CXX executable ../bin64/drcpusim_ops
[ 47%] Building CXX object deps/dynamorio/clients/drcachesim/CMakeFiles/drmemtrace_analyzer.dir/reader/config_reader.cpp.o
[ 47%] Building CXX object deps/dynamorio/clients/drcachesim/CMakeFiles/drmemtrace_analyzer.dir/reader/reader.cpp.o
[ 48%] Building CXX object deps/dynamorio/clients/drcachesim/CMakeFiles/drmemtrace_analyzer.dir/reader/compressed_file_reader.cpp.o
[ 48%] Building CXX object deps/dynamorio/clients/drcachesim/CMakeFiles/drmemtrace_analyzer.dir/reader/file_reader.cpp.o
[ 48%] Building CXX object deps/dynamorio/clients/drcachesim/CMakeFiles/drmemtrace_analyzer.dir/reader/snappy_file_reader.cpp.o
[ 48%] Building CXX object deps/dynamorio/clients/drcachesim/CMakeFiles/drmemtrace_analyzer.dir/reader/crc32c.cpp.o
[ 49%] Linking CXX static library ../lib64/release/libdrmemtrace_basic_counts.a
[ 49%] Built target drcpusim_ops
[ 49%] Generating drcpusim.dox
[ 49%] Built target drcpusim_docs
[ 49%] Built target drmemtrace_basic_counts
[ 49%] Linking CXX static library ../lib64/release/libdrmemtrace_histogram.a
[ 49%] Built target drmemtrace_histogram
[ 49%] Linking C shared library ../lib64/release/libdrpreload.so
[ 49%] Built target drpreload
[ 49%] Linking CXX static library ../lib64/release/libdrmemtrace_reuse_time.a
[ 49%] Linking C static library ../lib64/libdrconfiglib.a
[ 49%] Built target drmemtrace_reuse_time
[ 49%] Built target drconfiglib
[ 49%] Building C object deps/dynamorio/tools/CMakeFiles/drconfig.dir/drdeploy.c.o
[ 49%] Linking C static library ../lib64/libdrdecode.a
[ 49%] Linking CXX static library ../lib64/release/libdrmemtrace_reuse_distance.a
[ 49%] Linking CXX static library ../lib64/release/libdrmemtrace_func_view.a
[ 49%] Built target drmemtrace_reuse_distance
[ 49%] Built target drdecode
[ 49%] Built target drmemtrace_func_view
[ 49%] Building C object deps/dynamorio/core/CMakeFiles/drinjectlib.dir/unix/injector.c.o
[ 49%] Building CXX object deps/dynamorio/clients/drdisas/CMakeFiles/drdisas.dir/drdisas.cpp.o
[ 49%] Building C object deps/dynamorio/core/CMakeFiles/drinjectlib.dir/config.c.o
[ 50%] Building C object deps/dynamorio/core/CMakeFiles/drinjectlib.dir/string.c.o
[ 50%] Building C object deps/dynamorio/core/CMakeFiles/drinjectlib.dir/io.c.o
[ 50%] Linking C executable ../bin64/drconfig
CMake Error at /home/arcak-lab/scarab/src/deps/dynamorio/core/CMake_readelf.cmake:146 (message):
  *** Error:
  /home/arcak-lab/scarab/src/build/opt/deps/dynamorio/bin64/drconfig has
  too-recent import: GLOBAL DEFAULT UND _[...]@GLIBC_2.34 (4)



make[3]: *** [deps/dynamorio/tools/CMakeFiles/drconfig.dir/build.make:102: deps/dynamorio/bin64/drconfig] Error 1
make[3]: *** Deleting file 'deps/dynamorio/bin64/drconfig'
make[2]: *** [CMakeFiles/Makefile2:1219: deps/dynamorio/tools/CMakeFiles/drconfig.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
[ 50%] Linking CXX static library ../lib64/release/libdrmemtrace_simulator.a
[ 50%] Built target drmemtrace_simulator
[ 50%] Linking C static library ../lib64/libdrinjectlib.a
make[2]: *** [CMakeFiles/Makefile2:918: deps/dynamorio/core/CMakeFiles/dynamorio.dir/all] Error 2
make[2]: *** [CMakeFiles/Makefile2:946: deps/dynamorio/core/CMakeFiles/dynamorio_static.dir/all] Error 2
[ 50%] Built target drinjectlib
[ 50%] Linking CXX static library ../lib64/release/libdrmemtrace_analyzer.a
[ 50%] Linking CXX executable ../bin64/drdisas
[ 50%] Built target drmemtrace_analyzer
[ 50%] Linking CXX executable ../bin64/drcachesim_ops
[ 50%] Built target drdisas
[ 50%] Built target drcachesim_ops
[ 51%] Linking CXX static library libpin_lib_for_scarab.a
[ 51%] Built target pin_lib_for_scarab
[ 51%] Linking CXX static library libramulator.a
[ 51%] Built target ramulator
make[1]: *** [Makefile:156: all] Error 2
make: *** [Makefile:79: build/opt/scarab_phony] Error 2

Describe the bug
The help text for Scarab describes an option that does not appear to exist in Scarab, now.

To Reproduce
Steps to reproduce the behavior:

1. Run scarab --help -> Help text describes --exe option
2. Run scarab --exe ls -> Error says, FATAL ERROR (P=0 O=0 I=0 C=0): Unknown parameter '--exe'.

Screenshots

I am a bit confused with the memory system (let me know if there is
some documentation that I have missed).

1. I am not finding the usual L1, L2, L3 organization. Dcache seems to
   be the L1. L1 seems to be the L2. Where is the LLC and what is an MLC?

2. Could you give a quick summary about the most important functions
   that a memory request uses to traverse the memory hierarchy?

3. I want to observe load PCs with the highest memory latency (say
   those that miss L2 or L3) can you point me to some code where I can
   instrument this? I considered op->done_cycle but it does not seem to
   be updated anywhere in the memory hierarchy.

thanks

This is part bug report and part question.
After using DynamaRIO to generate a trace (command is included at the end), I try to run the trace through Scarab using the following command:

scarab  \
        --frontend memtrace  \
        --inst_limit 500000 \
        --fetch_off_path_ops 0 \
        --cbp_trace_r0=traces \
        --memtrace_modules_log=traces/drmemtrace.ls.00079.7109.dir/raw

The output says, Invalid header for input file #0 / Failed to read from trace and proceeds to go into an infinite loop printing out "Fast forwarded XXXXXXXXX instructions" forever. The full head of the output is included below.
I don't know how to solve this problem because I don't know which "header" is meant in Invalid header for input file #0.

Scarab gitrev: 5c58dea
Invalid header for input file #0
Failed to read from trace
Fast forwarded 10000000 instructions.
Fast forwarded 20000000 instructions.
Fast forwarded 30000000 instructions.
Fast forwarded 40000000 instructions.
Fast forwarded 50000000 instructions.
Fast forwarded 60000000 instructions.
Fast forwarded 70000000 instructions.
Fast forwarded 80000000 instructions.
Fast forwarded 90000000 instructions.
Fast forwarded 100000000 instructions.
Fast forwarded 110000000 instructions.
Fast forwarded 120000000 instructions.
.
.
.

The "bug report" part of this issue is that Scarab should not enter an infinite loop if it fails to read the trace (I waited several hours for it to finish because I missed the message at the top, which quickly went off-screen). It would also be helpful for the error message to specify what is "input file #0" and clarify what makes it invalid.

The command I am using to generate the trace is

drrun \
        -root $DYNAMORIO_ROOT \
        -t drcachesim \
        -offline \
        -outdir traces \
        -- \
        ls \

# We run run_portabilize_trace.sh in the traces directory.
cd traces
bash $SCARAB_ROOT/utils/memtrace/run_portabilize_trace.sh

When a memory request is created in Scarab, the various queues in the memory system are scanned to ensure there is no duplicate request.

However, Scarab does not appear to scan the Ramulator queues, potentially leading to duplicate memory requests.

Hello,
I wanted to ask if Scarab does take a checkpoint on a mispredict while executing in the wrong path. (Mispredict under Mispredict)
Thanks - Ioannis

In the project README, the link https://github.com/hpsresearchgroup/scarab/blob/master/docs/doxygen/index.html to the auto-generated software documentation is broken.

Hi, I'm trying to implement a prefetching policy in Scarab and I need metadata about the cache like the number of sets/ways the cache has. I see the Cache object has that information as a field, but where is the Cache instance I can get that information from?

Let me paste the code snippet from bp.c:600 first which will set up the context for the question:

/******************************************************************************/
/* bp_target_known_op: called on cf ops when the real target is known
   (either decode time or execute time) */

void bp_target_known_op(Bp_Data* bp_data, Op* op) {
  ASSERT(bp_data->proc_id, bp_data->proc_id == op->proc_id);
  ASSERT(bp_data->proc_id, op->table_info->cf_type);

  // if it was a btb miss, it is time to write it into the btb
  if(op->oracle_info.btb_miss)
    bp_data->bp_btb->update_func(bp_data, op);

  // special case updates
  switch(op->table_info->cf_type) {
    case CF_ICALL:  // fall through
    case CF_IBR:
      if(ENABLE_IBP) {
        if(IBTB_OFF_PATH_WRITES || !op->off_path) {
          bp_data->bp_ibtb->update_func(bp_data, op);
        }
      }
      break;
    default:
      break;  // do nothing
  }
}

Based on the source code, the current bpu implementation will update (or add if not present) a BTB entry even though the branch has already been identified (decoded) as indirect call/jump or return. If ENABLE_CRS and ENABLE_IBP both are FALSE, this update makes sense. However, why would current bpu implementation update and waste BTB entries when ENABLE_IBP and ENABLE_CRS are TRUE?