Hi, I'm new to gem5 and trying to follow the official tutorial [1] to build an x86 opt target from commit hash 48b4788. The compilation failed with Error 134. Outputs didn't seem to be meaningful - they are just normal building messages and ended with Error 134. I shall attach a detailed build output at the end of this email. The build command I used was `python3 `which scons` build/X86/gem5.opt`. My python3 version is 3.8.10. My scons version is 3.1.2. I've checked all the other dependencies and they seem to be fine. My machine is a physical server with ubuntu 20.04 running Linux 5.15. In addition, every time I remove the built directory and rebuilt, the file names before the Error 134 message are different. e.g., the attached output has "scons: *** [build/X86/cpu/o3/O3Checker.py.cc] Error 134", but the file name would different across different builds. Is there a way to narrow down this issue? Thanks! Kevin [1] https://www.gem5.org/documentation/learning_gem5/part1/building/ ============== kaiwenx@entropy:/u2/kaiwenx/dev/gem5$ python3 `which scons` build/X86/gem5.opt -j52 scons: Reading SConscript files ... Mkdir("/u2/kaiwenx/dev/gem5/build/X86/gem5.build") Checking for linker -Wl,--as-needed support... yes Checking for compiler -gz support... yes Checking for linker -gz support... yes Info: Using Python config: python3-config Checking for C header file Python.h... yes Checking Python version... 3.8.16 Checking for accept(0,0,0) in C++ library None... yes Checking for zlibVersion() in C++ library z... yes Checking for C library tcmalloc_minimal... yes Building in /u2/kaiwenx/dev/gem5/build/X86 Variables file(s) /u2/kaiwenx/dev/gem5/build/X86/gem5.build/variables or /u2/kaiwenx/dev/gem5/build/variables/X86 not found, using defaults in /u2/kaiwenx/dev/gem5/build_opts/X86 Checking size of struct kvm_xsave ... yes Checking for C header file linux/if_tun.h... yes Checking for pkg-config package protobuf... yes Checking for GOOGLE_PROTOBUF_VERIFY_VERSION in C++ library protobuf... yes Checking for backtrace_symbols_fd((void *)1, 0, 0) in C library None... yes Checking for C header file linux/kvm.h... yes Checking for timer_create(CLOCK_MONOTONIC, NULL, NULL) in C library None... no Checking for timer_create(CLOCK_MONOTONIC, NULL, NULL) in C library rt... yes Checking for member exclude_host in struct perf_event_attr...yes Checking for shm_open("/test", 0, 0) in C library None... yes Checking for C header file fenv.h... yes Checking for C header file png.h... yes Checking for clock_nanosleep(0,0,NULL,NULL) in C library None... yes Checking for C header file valgrind/valgrind.h... yes Warning: Deprecated namespaces are not supported by this compiler. Please make sure to check the mailing list for deprecation announcements. Checking for pkg-config package hdf5-serial... yes Checking for H5Fcreate("", 0, 0, 0) in C library hdf5... yes Checking for H5::H5File("", 0) in C++ library hdf5_cpp... yes Checking whether __i386__ is declared... no Checking whether __x86_64__ is declared... yes Checking for compiler -Wno-self-assign-overloaded support... yes Checking for linker -Wno-free-nonheap-object support... yes scons: done reading SConscript files. scons: Building targets ... [ CXX] src/python/gem5py.cc -> X86/python/gem5py.pyo [ SLICC] src/mem/ruby/protocol/MESI_Two_Level.slicc -> X86/mem/ruby/protocol/AccessPermission.cc, X86/mem/ruby/protocol/AccessPermission.hh, X86/mem/ruby/protocol/AccessType.cc, X86/mem/ruby/protocol/AccessType.hh, X86/mem/ruby/protocol/CacheRequestType.cc, X86/mem/ruby/protocol/CacheRequestType.hh, X86/mem/ruby/protocol/CacheResourceType.cc, X86/mem/ruby/protocol/CacheResourceType.hh, X86/mem/ruby/protocol/CoherenceRequestType.cc, X86/mem/ruby/protocol/CoherenceRequestType.hh, X86/mem/ruby/protocol/CoherenceResponseType.cc, X86/mem/ruby/protocol/CoherenceResponseType.hh, X86/mem/ruby/protocol/DMASequencerRequestType.cc, X86/mem/ruby/protocol/DMASequencerRequestType.hh, X86/mem/ruby/protocol/DMA_Controller.cc, X86/mem/ruby/protocol/DMA_Controller.hh, X86/mem/ruby/protocol/DMA_Controller.py, X86/mem/ruby/protocol/DMA_Event.cc, X86/mem/ruby/protocol/DMA_Event.hh, X86/mem/ruby/protocol/DMA_State.cc, X86/mem/ruby/protocol/DMA_State.hh, X86/mem/ruby/protocol/DMA_TBE.cc, X86/mem/ruby/protocol/DMA_TBE.hh, X86/mem/ruby/protocol/DMA_Transitions.cc, X86/mem/ruby/protocol/DMA_Wakeup.cc, X86/mem/ruby/protocol/DirectoryRequestType.cc, X86/mem/ruby/protocol/DirectoryRequestType.hh, X86/mem/ruby/protocol/Directory_Controller.cc, X86/mem/ruby/protocol/Directory_Controller.hh, X86/mem/ruby/protocol/Directory_Controller.py, X86/mem/ruby/protocol/Directory_Entry.cc, X86/mem/ruby/protocol/Directory_Entry.hh, X86/mem/ruby/protocol/Directory_Event.cc, X86/mem/ruby/protocol/Directory_Event.hh, X86/mem/ruby/protocol/Directory_State.cc, X86/mem/ruby/protocol/Directory_State.hh, X86/mem/ruby/protocol/Directory_TBE.cc, X86/mem/ruby/protocol/Directory_TBE.hh, X86/mem/ruby/protocol/Directory_Transitions.cc, X86/mem/ruby/protocol/Directory_Wakeup.cc, X86/mem/ruby/protocol/HtmCallbackMode.cc, X86/mem/ruby/protocol/HtmCallbackMode.hh, X86/mem/ruby/protocol/HtmFailedInCacheReason.cc, X86/mem/ruby/protocol/HtmFailedInCacheReason.hh, X86/mem/ruby/protocol/InvalidateGeneratorStatus.cc, X86/mem/ruby/protocol/InvalidateGeneratorStatus.hh, X86/mem/ruby/protocol/L1Cache_Controller.cc, X86/mem/ruby/protocol/L1Cache_Controller.hh, X86/mem/ruby/protocol/L1Cache_Controller.py, X86/mem/ruby/protocol/L1Cache_Entry.cc, X86/mem/ruby/protocol/L1Cache_Entry.hh, X86/mem/ruby/protocol/L1Cache_Event.cc, X86/mem/ruby/protocol/L1Cache_Event.hh, X86/mem/ruby/protocol/L1Cache_State.cc, X86/mem/ruby/protocol/L1Cache_State.hh, X86/mem/ruby/protocol/L1Cache_TBE.cc, X86/mem/ruby/protocol/L1Cache_TBE.hh, X86/mem/ruby/protocol/L1Cache_Transitions.cc, X86/mem/ruby/protocol/L1Cache_Wakeup.cc, X86/mem/ruby/protocol/L2Cache_Controller.cc, X86/mem/ruby/protocol/L2Cache_Controller.hh, X86/mem/ruby/protocol/L2Cache_Controller.py, X86/mem/ruby/protocol/L2Cache_Entry.cc, X86/mem/ruby/protocol/L2Cache_Entry.hh, X86/mem/ruby/protocol/L2Cache_Event.cc, X86/mem/ruby/protocol/L2Cache_Event.hh, X86/mem/ruby/protocol/L2Cache_State.cc, X86/mem/ruby/protocol/L2Cache_State.hh, X86/mem/ruby/protocol/L2Cache_TBE.cc, X86/mem/ruby/protocol/L2Cache_TBE.hh, X86/mem/ruby/protocol/L2Cache_Transitions.cc, X86/mem/ruby/protocol/L2Cache_Wakeup.cc, X86/mem/ruby/protocol/LinkDirection.cc, X86/mem/ruby/protocol/LinkDirection.hh, X86/mem/ruby/protocol/LockStatus.cc, X86/mem/ruby/protocol/LockStatus.hh, X86/mem/ruby/protocol/MachineType.cc, X86/mem/ruby/protocol/MachineType.hh, X86/mem/ruby/protocol/MaskPredictorIndex.cc, X86/mem/ruby/protocol/MaskPredictorIndex.hh, X86/mem/ruby/protocol/MaskPredictorTraining.cc, X86/mem/ruby/protocol/MaskPredictorTraining.hh, X86/mem/ruby/protocol/MaskPredictorType.cc, X86/mem/ruby/protocol/MaskPredictorType.hh, X86/mem/ruby/protocol/MemoryControlRequestType.cc, X86/mem/ruby/protocol/MemoryControlRequestType.hh, X86/mem/ruby/protocol/MemoryMsg.cc, X86/mem/ruby/protocol/MemoryMsg.hh, X86/mem/ruby/protocol/MemoryRequestType.cc, X86/mem/ruby/protocol/MemoryRequestType.hh, X86/mem/ruby/protocol/MessageSizeType.cc, X86/mem/ruby/protocol/MessageSizeType.hh, X86/mem/ruby/protocol/PrefetchBit.cc, X86/mem/ruby/protocol/PrefetchBit.hh, X86/mem/ruby/protocol/RequestMsg.cc, X86/mem/ruby/protocol/RequestMsg.hh, X86/mem/ruby/protocol/RequestStatus.cc, X86/mem/ruby/protocol/RequestStatus.hh, X86/mem/ruby/protocol/ResponseMsg.cc, X86/mem/ruby/protocol/ResponseMsg.hh, X86/mem/ruby/protocol/RubyAccessMode.cc, X86/mem/ruby/protocol/RubyAccessMode.hh, X86/mem/ruby/protocol/RubyRequestType.cc, X86/mem/ruby/protocol/RubyRequestType.hh, X86/mem/ruby/protocol/SequencerMsg.cc, X86/mem/ruby/protocol/SequencerMsg.hh, X86/mem/ruby/protocol/SequencerRequestType.cc, X86/mem/ruby/protocol/SequencerRequestType.hh, X86/mem/ruby/protocol/SequencerStatus.cc, X86/mem/ruby/protocol/SequencerStatus.hh, X86/mem/ruby/protocol/SeriesRequestGeneratorStatus.cc, X86/mem/ruby/protocol/SeriesRequestGeneratorStatus.hh, X86/mem/ruby/protocol/TesterStatus.cc, X86/mem/ruby/protocol/TesterStatus.hh, X86/mem/ruby/protocol/TransitionResult.cc, X86/mem/ruby/protocol/TransitionResult.hh, X86/mem/ruby/protocol/Types.hh MESI_Two_Level-L1cache.sm:246: Warning: Non-void return ignored, return type is 'bool' MESI_Two_Level-L1cache.sm:248: Warning: Non-void return ignored, return type is 'bool' MESI_Two_Level-L1cache.sm:887: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-L1cache.sm:999: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-L1cache.sm:740: Warning: Unused action: e_sendAckToRequestor, send invalidate ack to requestor (could be L2 or L1) MESI_Two_Level-L2cache.sm:235: Warning: Non-void return ignored, return type is 'bool' MESI_Two_Level-L2cache.sm:237: Warning: Non-void return ignored, return type is 'bool' MESI_Two_Level-L2cache.sm:594: Warning: Unused action: fw_sendFwdInvToSharers, invalidate sharers for request MESI_Two_Level-L2cache.sm:764: Warning: Unused action: kk_removeRequestSharer, Remove L1 Request sharer from list MESI_Two_Level-L2cache.sm:780: Warning: Unused action: mm_markExclusive, set the exclusive owner MESI_Two_Level-dir.sm:160: Warning: Non-void return ignored, return type is 'bool' MESI_Two_Level-dir.sm:294: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-dir.sm:298: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-dir.sm:302: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-dir.sm:348: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-dir.sm:351: Warning: Unused action: p_popIncomingDMARequestQueue, Pop incoming DMA queue MESI_Two_Level-dma.sm:189: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-dma.sm:193: Warning: Non-void return ignored, return type is 'Tick' [ CXX] src/python/embedded.cc -> X86/python/embedded.pyo [EMBED BLOB] src/python/importer.py, m5ImporterCode -> X86/python/m5ImporterCode.cc, X86/python/m5ImporterCode.hh [ DEFINES] -> X86/python/m5/defines.py [CONFIG H] HAVE_DEPRECATED_NAMESPACE, 0 -> X86/config/have_deprecated_namespace.hh [ CXX] src/arch/generic/htm.cc -> X86/arch/generic/htm.o [ISA DESC] src/arch/x86/isa/main.isa -> X86/arch/x86/generated/decoder-g.cc.inc, X86/arch/x86/generated/decoder-ns.cc.inc, X86/arch/x86/generated/decode-method.cc.inc, X86/arch/x86/generated/decoder.hh, X86/arch/x86/generated/decoder-g.hh.inc, X86/arch/x86/generated/decoder-ns.hh.inc, X86/arch/x86/generated/exec-g.cc.inc, X86/arch/x86/generated/exec-ns.cc.inc, X86/arch/x86/generated/decoder.cc, X86/arch/x86/generated/inst-constrs.cc, X86/arch/x86/generated/generic_cpu_exec.cc [CONFIG H] HAVE_PERF_ATTR_EXCLUDE_HOST, 1 -> X86/config/have_perf_attr_exclude_host.hh [CONFIG H] HAVE_TUNTAP, 1 -> X86/config/have_tuntap.hh [ PROTOC] src/proto/inst_dep_record.proto -> X86/proto/inst_dep_record.pb.cc, X86/proto/inst_dep_record.pb.h [ PROTOC] src/proto/packet.proto -> X86/proto/packet.pb.cc, X86/proto/packet.pb.h [ PROTOC] src/proto/inst.proto -> X86/proto/inst.pb.cc, X86/proto/inst.pb.h Generating LALR tables [ CXX] src/proto/protobuf.cc -> X86/proto/protobuf.o [ CXX] src/sim/async.cc -> X86/sim/async.o [ CXX] src/sim/backtrace_glibc.cc -> X86/sim/backtrace_glibc.o [ CXX] src/sim/cur_tick.cc -> X86/sim/cur_tick.o [VER TAGS] -> X86/sim/tags.cc [ CXX] src/sim/py_interact.cc -> X86/sim/py_interact.o [ CXX] src/sim/init.cc -> X86/sim/init.o [ CXX] src/sim/main.cc -> X86/sim/main.o [ CXX] src/sim/python.cc -> X86/sim/python.o [ CXX] src/sim/se_signal.cc -> X86/sim/se_signal.o [ CXX] src/sim/linear_solver.cc -> X86/sim/linear_solver.o [CONFIG H] HAVE_PROTOBUF, 1 -> X86/config/have_protobuf.hh [ CXX] src/mem/htm.cc -> X86/mem/htm.o [CONFIG H] BUILD_GPU, 0 -> X86/config/build_gpu.hh [ CFG ISA] -> X86/config/the_gpu_isa.hh [ CXX] src/mem/ruby/profiler/StoreTrace.cc -> X86/mem/ruby/profiler/StoreTrace.o [ CXX] src/mem/ruby/common/BoolVec.cc -> X86/mem/ruby/common/BoolVec.o [ CXX] src/mem/ruby/common/IntVec.cc -> X86/mem/ruby/common/IntVec.o [ CXX] src/python/embedded.cc -> X86/python/embedded.o [CONFIG H] HAVE_HDF5, 1 -> X86/config/have_hdf5.hh [ CXX] src/base/atomicio.cc -> X86/base/atomicio.o [ CXX] src/base/bitfield.cc -> X86/base/bitfield.o [CONFIG H] HAVE_PNG, 1 -> X86/config/have_png.hh [CONFIG H] HAVE_FENV, 1 -> X86/config/have_fenv.hh [CONFIG H] HAVE_VALGRIND, 1 -> X86/config/have_valgrind.hh [CONFIG H] USE_POSIX_CLOCK, 1 -> X86/config/use_posix_clock.hh [ CXX] src/base/version.cc -> X86/base/version.o [ CXX] src/base/temperature.cc -> X86/base/temperature.o [ CXX] src/base/types.cc -> X86/base/types.o [ CXX] src/systemc/dt/int/messages.cc -> X86/systemc/dt/int/messages.o [ CXX] src/systemc/dt/int/sc_int_base.cc -> X86/systemc/dt/int/sc_int_base.o [ CXX] src/systemc/dt/int/sc_int_mask.cc -> X86/systemc/dt/int/sc_int_mask.o [ CXX] src/systemc/dt/int/sc_length_param.cc -> X86/systemc/dt/int/sc_length_param.o [ CXX] src/systemc/dt/int/sc_nbexterns.cc -> X86/systemc/dt/int/sc_nbexterns.o [ CXX] src/systemc/dt/int/sc_nbutils.cc -> X86/systemc/dt/int/sc_nbutils.o [ CXX] src/systemc/dt/int/sc_signed.cc -> X86/systemc/dt/int/sc_signed.o [ CXX] src/systemc/dt/int/sc_uint_base.cc -> X86/systemc/dt/int/sc_uint_base.o [ CXX] src/systemc/dt/int/sc_unsigned.cc -> X86/systemc/dt/int/sc_unsigned.o [ CXX] src/systemc/dt/bit/messages.cc -> X86/systemc/dt/bit/messages.o [ CXX] src/base/time.cc -> X86/base/time.o [ CXX] src/base/fiber.cc -> X86/base/fiber.o [ CXX] src/base/fenv.cc -> X86/base/fenv.o [ CXX] src/python/pybind11/stats.cc -> X86/python/pybind11/stats.o [ CXX] X86/sim/tags.cc -> .o [ LINK] -> X86/gem5py [ CXX] X86/proto/inst.pb.cc -> .o [ CXX] X86/proto/packet.pb.cc -> .o [ CXX] X86/proto/inst_dep_record.pb.cc -> .o [ CXX] src/cpu/kvm/perfevent.cc -> X86/cpu/kvm/perfevent.o [ CXX] src/dev/net/pktfifo.cc -> X86/dev/net/pktfifo.o [ CXX] src/base/logging.cc -> X86/base/logging.o [ CXX] src/sim/core.cc -> X86/sim/core.o [ CXX] src/base/loader/image_file_data.cc -> X86/base/loader/image_file_data.o [ CXX] src/sim/globals.cc -> X86/sim/globals.o [ CXX] src/base/inifile.cc -> X86/base/inifile.o [ CXX] src/dev/ps2/types.cc -> X86/dev/ps2/types.o [ CXX] src/base/stats/info.cc -> X86/base/stats/info.o [ CXX] src/base/loader/symtab.cc -> X86/base/loader/symtab.o [ CXX] src/mem/ruby/structures/PersistentTable.cc -> X86/mem/ruby/structures/PersistentTable.o [ CXX] src/kern/operatingsystem.cc -> X86/kern/operatingsystem.o [ CXX] src/arch/x86/types.cc -> X86/arch/x86/types.o [ CXX] src/base/cprintf.cc -> X86/base/cprintf.o [ CXX] src/base/stats/text.cc -> X86/base/stats/text.o [ CXX] src/mem/ruby/structures/TBEStorage.cc -> X86/mem/ruby/structures/TBEStorage.o [ CXX] src/base/inet.cc -> X86/base/inet.o [ CXX] src/mem/ruby/profiler/AccessTraceForAddress.cc -> X86/mem/ruby/profiler/AccessTraceForAddress.o [ CXX] src/base/hostinfo.cc -> X86/base/hostinfo.o [ CXX] src/mem/cache/compressors/encoders/huffman.cc -> X86/mem/cache/compressors/encoders/huffman.o [ CXX] src/sim/port.cc -> X86/sim/port.o [ CXX] src/cpu/kvm/device.cc -> X86/cpu/kvm/device.o [ CXX] src/base/random.cc -> X86/base/random.o [ CXX] src/mem/ruby/common/NetDest.cc -> X86/mem/ruby/common/NetDest.o [ CXX] src/base/stats/storage.cc -> X86/base/stats/storage.o [ CXX] src/sim/mathexpr.cc -> X86/sim/mathexpr.o [ CXX] src/cpu/pred/ras.cc -> X86/cpu/pred/ras.o [EMBED PY] src/cpu/o3/O3Checker.py -> X86/cpu/o3/O3Checker.py.cc [ TRACING] -> X86/debug/TerminalVerbose.cc [ TRACING] -> X86/debug/RubyHitMiss.hh [ TRACING] -> X86/debug/EthernetSM.cc [ TRACING] -> X86/debug/CacheVerbose.hh [EMBED PY] src/python/m5/ext/pystats/serializable_stat.py -> X86/python/m5/ext/pystats/serializable_stat.py.cc [ TRACING] -> X86/debug/CommMonitor.cc [EMBED PY] src/mem/MemDelay.py -> X86/mem/MemDelay.py.cc [ TRACING] -> X86/debug/Activity.cc [ TRACING] -> X86/debug/EthernetSM.hh [ TRACING] -> X86/debug/VNC.cc [ TRACING] -> X86/debug/RubyQueue.cc [EMBED PY] src/learning_gem5/part2/SimpleCache.py -> X86/learning_gem5/part2/SimpleCache.py.cc [ CXX] X86/debug/EthernetSM.cc -> .o [EMBED PY] src/python/gem5/components/cachehierarchies/ruby/caches/mesi_three_level/l3_cache.py -> X86/python/gem5/components/cachehierarchies/ruby/caches/mesi_three_level/l3_cache.py.cc [EMBED PY] src/python/gem5/components/cachehierarchies/ruby/__init__.py -> X86/python/gem5/components/cachehierarchies/ruby/__init__.py.cc Aborted (core dumped) scons: *** [build/X86/cpu/o3/O3Checker.py.cc] Error 134 Aborted (core dumped) Aborted (core dumped) scons: *** [build/X86/python/m5/ext/pystats/serializable_stat.py.cc] Error 134 scons: *** [build/X86/mem/MemDelay.py.cc] Error 134 Aborted (core dumped) scons: *** [build/X86/learning_gem5/part2/SimpleCache.py.cc] Error 134 Aborted (core dumped) scons: *** [build/X86/python/gem5/components/cachehierarchies/ruby/caches/mesi_three_level/l3_cache.py.cc] Error 134 Aborted (core dumped) scons: *** [build/X86/python/gem5/components/cachehierarchies/ruby/__init__.py.cc] Error 134 scons: building terminated because of errors. *** Summary of Warnings *** Warning: Deprecated namespaces are not supported by this compiler. Please make sure to check the mailing list for deprecation announcements.

On 8/5/2023 2:16 AM, Kaiwen Xue via gem5-users wrote: > Hi, > > I'm new to gem5 and trying to follow the official tutorial [1] to > build an x86 opt target from commit hash 48b4788. > > The compilation failed with Error 134. Outputs didn't seem to be > meaningful - they are just normal building messages and ended with > Error 134. I shall attach a detailed build output at the end of this > email. > > The build command I used was `python3 `which scons` > build/X86/gem5.opt`. My python3 version is 3.8.10. My scons version is > 3.1.2. I've checked all the other dependencies and they seem to be > fine. My machine is a physical server with ubuntu 20.04 running Linux > 5.15. > > In addition, every time I remove the built directory and rebuilt, the > file names before the Error 134 message are different. e.g., the > attached output has "scons: *** [build/X86/cpu/o3/O3Checker.py.cc] > Error 134", but the file name would different across different builds. > > Is there a way to narrow down this issue? > > Thanks! > Kevin My guess is that you ran out of memory - some of the compilations need quite a lot! Since scons typically builds in parallel, you get some variation in which jobs are running when. You *might* try compiling just one thing at a time (-j1). No need to rm everything - you can continue where it aborted. But still, if even one job demands too much memory, you will fail again. If you're running in a virtual machine, increase its main memory size. As I recall, something like 5-6Gb are needed to build gem5. Using somewhat more than that won't hurt. Best - EM

On Sat, Aug 5, 2023 at 5:13 AM Eliot Moss via gem5-users <gem5-users@gem5.org> wrote: > > On 8/5/2023 2:16 AM, Kaiwen Xue via gem5-users wrote: > > Hi, > > > > I'm new to gem5 and trying to follow the official tutorial [1] to > > build an x86 opt target from commit hash 48b4788. > > > > The compilation failed with Error 134. Outputs didn't seem to be > > meaningful - they are just normal building messages and ended with > > Error 134. I shall attach a detailed build output at the end of this > > email. > > > > The build command I used was `python3 `which scons` > > build/X86/gem5.opt`. My python3 version is 3.8.10. My scons version is > > 3.1.2. I've checked all the other dependencies and they seem to be > > fine. My machine is a physical server with ubuntu 20.04 running Linux > > 5.15. > > > > In addition, every time I remove the built directory and rebuilt, the > > file names before the Error 134 message are different. e.g., the > > attached output has "scons: *** [build/X86/cpu/o3/O3Checker.py.cc] > > Error 134", but the file name would different across different builds. > > > > Is there a way to narrow down this issue? > > > > Thanks! > > Kevin > > My guess is that you ran out of memory - some of the compilations need quite a > lot! Since scons typically builds in parallel, you get some variation in > which jobs are running when. You *might* try compiling just one thing at a > time (-j1). No need to rm everything - you can continue where it aborted. > But still, if even one job demands too much memory, you will fail again. Hi Eliot, Thanks for the response! However, I have more than abundant resources on my server. It's not a virtual machine. It has more than 200GB of free disk space and 100GB of free memory. I can't continue where it aborted as well, because the error seemed to start repeating every time and more compilation wouldn't make more progress. I'm suspecting that might be a compiler bug though. The parser reported shift/reduce conflict: Generating LALR tables WARNING: 4 shift/reduce conflicts WARNING: 1 reduce/reduce conflict WARNING: reduce/reduce conflict in state 98 resolved using rule (params -> empty) WARNING: rejected rule (types -> empty) in state 98 which might lead to the following return type warnings in the cache coherence .sm file: MESI_Two_Level-L1cache.sm:246: Warning: Non-void return ignored, return type is 'bool' MESI_Two_Level-L1cache.sm:248: Warning: Non-void return ignored, return type is 'bool' MESI_Two_Level-L1cache.sm:887: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-L1cache.sm:999: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-L1cache.sm:740: Warning: Unused action: e_sendAckToRequestor, send invalidate ack to requestor (could be L2 or L1) MESI_Two_Level-L2cache.sm:235: Warning: Non-void return ignored, return type is 'bool' MESI_Two_Level-L2cache.sm:237: Warning: Non-void return ignored, return type is 'bool' MESI_Two_Level-L2cache.sm:594: Warning: Unused action: fw_sendFwdInvToSharers, invalidate sharers for request MESI_Two_Level-L2cache.sm:764: Warning: Unused action: kk_removeRequestSharer, Remove L1 Request sharer from list MESI_Two_Level-L2cache.sm:780: Warning: Unused action: mm_markExclusive, set the exclusive owner MESI_Two_Level-dir.sm:160: Warning: Non-void return ignored, return type is 'bool' MESI_Two_Level-dir.sm:294: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-dir.sm:298: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-dir.sm:302: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-dir.sm:348: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-dir.sm:351: Warning: Unused action: p_popIncomingDMARequestQueue, Pop incoming DMA queue MESI_Two_Level-dma.sm:189: Warning: Non-void return ignored, return type is 'Tick' MESI_Two_Level-dma.sm:193: Warning: Non-void return ignored, return type is 'Tick' Any idea why those happened? Any response or hints are appreciated! Thanks! Kevin -- Kaiwen Xue (Preferred Kevin) MSCS@CMU https://kevinrsx.github.io

On Sat, Aug 5, 2023 at 10:50 PM Kaiwen Xue <kaiwenx@andrew.cmu.edu> wrote: > > On Sat, Aug 5, 2023 at 5:13 AM Eliot Moss via gem5-users > <gem5-users@gem5.org> wrote: > > > > On 8/5/2023 2:16 AM, Kaiwen Xue via gem5-users wrote: > > > Hi, > > > > > > I'm new to gem5 and trying to follow the official tutorial [1] to > > > build an x86 opt target from commit hash 48b4788. > > > > > > The compilation failed with Error 134. Outputs didn't seem to be > > > meaningful - they are just normal building messages and ended with > > > Error 134. I shall attach a detailed build output at the end of this > > > email. > > > > > > The build command I used was `python3 `which scons` > > > build/X86/gem5.opt`. My python3 version is 3.8.10. My scons version is > > > 3.1.2. I've checked all the other dependencies and they seem to be > > > fine. My machine is a physical server with ubuntu 20.04 running Linux > > > 5.15. > > > > > > In addition, every time I remove the built directory and rebuilt, the > > > file names before the Error 134 message are different. e.g., the > > > attached output has "scons: *** [build/X86/cpu/o3/O3Checker.py.cc] > > > Error 134", but the file name would different across different builds. > > > > > > Is there a way to narrow down this issue? > > > > > > Thanks! > > > Kevin > > > > My guess is that you ran out of memory - some of the compilations need quite a > > lot! Since scons typically builds in parallel, you get some variation in > > which jobs are running when. You *might* try compiling just one thing at a > > time (-j1). No need to rm everything - you can continue where it aborted. > > But still, if even one job demands too much memory, you will fail again. > > Hi Eliot, > > Thanks for the response! However, I have more than abundant resources > on my server. It's not a virtual machine. It has more than 200GB of > free disk space and 100GB of free memory. I can't continue where it > aborted as well, because the error seemed to start repeating every > time and more compilation wouldn't make more progress. > > I'm suspecting that might be a compiler bug though. The parser > reported shift/reduce conflict: > Generating LALR tables > WARNING: 4 shift/reduce conflicts > WARNING: 1 reduce/reduce conflict > WARNING: reduce/reduce conflict in state 98 resolved using rule > (params -> empty) > WARNING: rejected rule (types -> empty) in state 98 > > which might lead to the following return type warnings in the cache > coherence .sm file: > MESI_Two_Level-L1cache.sm:246: Warning: Non-void return ignored, > return type is 'bool' > MESI_Two_Level-L1cache.sm:248: Warning: Non-void return ignored, > return type is 'bool' > MESI_Two_Level-L1cache.sm:887: Warning: Non-void return ignored, > return type is 'Tick' > MESI_Two_Level-L1cache.sm:999: Warning: Non-void return ignored, > return type is 'Tick' > MESI_Two_Level-L1cache.sm:740: Warning: Unused action: > e_sendAckToRequestor, send invalidate ack to requestor (could be L2 or > L1) > MESI_Two_Level-L2cache.sm:235: Warning: Non-void return ignored, > return type is 'bool' > MESI_Two_Level-L2cache.sm:237: Warning: Non-void return ignored, > return type is 'bool' > MESI_Two_Level-L2cache.sm:594: Warning: Unused action: > fw_sendFwdInvToSharers, invalidate sharers for request > MESI_Two_Level-L2cache.sm:764: Warning: Unused action: > kk_removeRequestSharer, Remove L1 Request sharer from list > MESI_Two_Level-L2cache.sm:780: Warning: Unused action: > mm_markExclusive, set the exclusive owner > MESI_Two_Level-dir.sm:160: Warning: Non-void return ignored, return > type is 'bool' > MESI_Two_Level-dir.sm:294: Warning: Non-void return ignored, return > type is 'Tick' > MESI_Two_Level-dir.sm:298: Warning: Non-void return ignored, return > type is 'Tick' > MESI_Two_Level-dir.sm:302: Warning: Non-void return ignored, return > type is 'Tick' > MESI_Two_Level-dir.sm:348: Warning: Non-void return ignored, return > type is 'Tick' > MESI_Two_Level-dir.sm:351: Warning: Unused action: > p_popIncomingDMARequestQueue, Pop incoming DMA queue > MESI_Two_Level-dma.sm:189: Warning: Non-void return ignored, return > type is 'Tick' > MESI_Two_Level-dma.sm:193: Warning: Non-void return ignored, return > type is 'Tick' > > Any idea why those happened? Any response or hints are appreciated! > > Thanks! > Kevin > > -- > Kaiwen Xue (Preferred Kevin) MSCS@CMU > https://kevinrsx.github.io Forgot to mention, my gcc/g++ version is 9.4.0 which comes with Ubuntu 20.04. - Kevin -- Kaiwen Xue (Preferred Kevin) MSCS@CMU https://kevinrsx.github.io

On 8/6/2023 1:50 AM, Kaiwen Xue via gem5-users wrote: > On Sat, Aug 5, 2023 at 5:13 AM Eliot Moss via gem5-users > <gem5-users@gem5.org> wrote: >> >> On 8/5/2023 2:16 AM, Kaiwen Xue via gem5-users wrote: >>> Hi, >>> >>> I'm new to gem5 and trying to follow the official tutorial [1] to >>> build an x86 opt target from commit hash 48b4788. >>> >>> The compilation failed with Error 134. Outputs didn't seem to be >>> meaningful - they are just normal building messages and ended with >>> Error 134. I shall attach a detailed build output at the end of this >>> email. >>> >>> The build command I used was `python3 `which scons` >>> build/X86/gem5.opt`. My python3 version is 3.8.10. My scons version is >>> 3.1.2. I've checked all the other dependencies and they seem to be >>> fine. My machine is a physical server with ubuntu 20.04 running Linux >>> 5.15. >>> >>> In addition, every time I remove the built directory and rebuilt, the >>> file names before the Error 134 message are different. e.g., the >>> attached output has "scons: *** [build/X86/cpu/o3/O3Checker.py.cc] >>> Error 134", but the file name would different across different builds. >>> >>> Is there a way to narrow down this issue? >>> >>> Thanks! >>> Kevin >> >> My guess is that you ran out of memory - some of the compilations need quite a >> lot! Since scons typically builds in parallel, you get some variation in >> which jobs are running when. You *might* try compiling just one thing at a >> time (-j1). No need to rm everything - you can continue where it aborted. >> But still, if even one job demands too much memory, you will fail again. > > Hi Eliot, > > Thanks for the response! However, I have more than abundant resources > on my server. It's not a virtual machine. It has more than 200GB of > free disk space and 100GB of free memory. I can't continue where it > aborted as well, because the error seemed to start repeating every > time and more compilation wouldn't make more progress. > > I'm suspecting that might be a compiler bug though. The parser > reported shift/reduce conflict: > Generating LALR tables > WARNING: 4 shift/reduce conflicts > WARNING: 1 reduce/reduce conflict > WARNING: reduce/reduce conflict in state 98 resolved using rule > (params -> empty) > WARNING: rejected rule (types -> empty) in state 98 > > which might lead to the following return type warnings in the cache > coherence .sm file: > MESI_Two_Level-L1cache.sm:246: Warning: Non-void return ignored, > return type is 'bool' > MESI_Two_Level-L1cache.sm:248: Warning: Non-void return ignored, > return type is 'bool' > MESI_Two_Level-L1cache.sm:887: Warning: Non-void return ignored, > return type is 'Tick' > MESI_Two_Level-L1cache.sm:999: Warning: Non-void return ignored, > return type is 'Tick' > MESI_Two_Level-L1cache.sm:740: Warning: Unused action: > e_sendAckToRequestor, send invalidate ack to requestor (could be L2 or > L1) > MESI_Two_Level-L2cache.sm:235: Warning: Non-void return ignored, > return type is 'bool' > MESI_Two_Level-L2cache.sm:237: Warning: Non-void return ignored, > return type is 'bool' > MESI_Two_Level-L2cache.sm:594: Warning: Unused action: > fw_sendFwdInvToSharers, invalidate sharers for request > MESI_Two_Level-L2cache.sm:764: Warning: Unused action: > kk_removeRequestSharer, Remove L1 Request sharer from list > MESI_Two_Level-L2cache.sm:780: Warning: Unused action: > mm_markExclusive, set the exclusive owner > MESI_Two_Level-dir.sm:160: Warning: Non-void return ignored, return > type is 'bool' > MESI_Two_Level-dir.sm:294: Warning: Non-void return ignored, return > type is 'Tick' > MESI_Two_Level-dir.sm:298: Warning: Non-void return ignored, return > type is 'Tick' > MESI_Two_Level-dir.sm:302: Warning: Non-void return ignored, return > type is 'Tick' > MESI_Two_Level-dir.sm:348: Warning: Non-void return ignored, return > type is 'Tick' > MESI_Two_Level-dir.sm:351: Warning: Unused action: > p_popIncomingDMARequestQueue, Pop incoming DMA queue > MESI_Two_Level-dma.sm:189: Warning: Non-void return ignored, return > type is 'Tick' > MESI_Two_Level-dma.sm:193: Warning: Non-void return ignored, return > type is 'Tick' > > Any idea why those happened? Any response or hints are appreciated! That looks to me like something coming from ruby, and that parser may be quite distinct from the one in g++. But I don't use ruby so I don't really know ... Sorry - EM

Hi Kevin, The error is quite odd, and it does look like it was hardware resource related. Can you try building gem5 from the official docker images here? The images have newer versions of gcc and scons I believe. If the problem persists then it's probably a bug in gem5. https://www.gem5.org/documentation/general_docs/building Regards, Hoa Nguyen On Sun, Aug 6, 2023, 03:26 Eliot Moss via gem5-users <gem5-users@gem5.org> wrote: > On 8/6/2023 1:50 AM, Kaiwen Xue via gem5-users wrote: > > On Sat, Aug 5, 2023 at 5:13 AM Eliot Moss via gem5-users > > <gem5-users@gem5.org> wrote: > >> > >> On 8/5/2023 2:16 AM, Kaiwen Xue via gem5-users wrote: > >>> Hi, > >>> > >>> I'm new to gem5 and trying to follow the official tutorial [1] to > >>> build an x86 opt target from commit hash 48b4788. > >>> > >>> The compilation failed with Error 134. Outputs didn't seem to be > >>> meaningful - they are just normal building messages and ended with > >>> Error 134. I shall attach a detailed build output at the end of this > >>> email. > >>> > >>> The build command I used was `python3 `which scons` > >>> build/X86/gem5.opt`. My python3 version is 3.8.10. My scons version is > >>> 3.1.2. I've checked all the other dependencies and they seem to be > >>> fine. My machine is a physical server with ubuntu 20.04 running Linux > >>> 5.15. > >>> > >>> In addition, every time I remove the built directory and rebuilt, the > >>> file names before the Error 134 message are different. e.g., the > >>> attached output has "scons: *** [build/X86/cpu/o3/O3Checker.py.cc] > >>> Error 134", but the file name would different across different builds. > >>> > >>> Is there a way to narrow down this issue? > >>> > >>> Thanks! > >>> Kevin > >> > >> My guess is that you ran out of memory - some of the compilations need > quite a > >> lot! Since scons typically builds in parallel, you get some variation > in > >> which jobs are running when. You *might* try compiling just one thing > at a > >> time (-j1). No need to rm everything - you can continue where it > aborted. > >> But still, if even one job demands too much memory, you will fail again. > > > > Hi Eliot, > > > > Thanks for the response! However, I have more than abundant resources > > on my server. It's not a virtual machine. It has more than 200GB of > > free disk space and 100GB of free memory. I can't continue where it > > aborted as well, because the error seemed to start repeating every > > time and more compilation wouldn't make more progress. > > > > I'm suspecting that might be a compiler bug though. The parser > > reported shift/reduce conflict: > > Generating LALR tables > > WARNING: 4 shift/reduce conflicts > > WARNING: 1 reduce/reduce conflict > > WARNING: reduce/reduce conflict in state 98 resolved using rule > > (params -> empty) > > WARNING: rejected rule (types -> empty) in state 98 > > > > which might lead to the following return type warnings in the cache > > coherence .sm file: > > MESI_Two_Level-L1cache.sm:246: Warning: Non-void return ignored, > > return type is 'bool' > > MESI_Two_Level-L1cache.sm:248: Warning: Non-void return ignored, > > return type is 'bool' > > MESI_Two_Level-L1cache.sm:887: Warning: Non-void return ignored, > > return type is 'Tick' > > MESI_Two_Level-L1cache.sm:999: Warning: Non-void return ignored, > > return type is 'Tick' > > MESI_Two_Level-L1cache.sm:740: Warning: Unused action: > > e_sendAckToRequestor, send invalidate ack to requestor (could be L2 or > > L1) > > MESI_Two_Level-L2cache.sm:235: Warning: Non-void return ignored, > > return type is 'bool' > > MESI_Two_Level-L2cache.sm:237: Warning: Non-void return ignored, > > return type is 'bool' > > MESI_Two_Level-L2cache.sm:594: Warning: Unused action: > > fw_sendFwdInvToSharers, invalidate sharers for request > > MESI_Two_Level-L2cache.sm:764: Warning: Unused action: > > kk_removeRequestSharer, Remove L1 Request sharer from list > > MESI_Two_Level-L2cache.sm:780: Warning: Unused action: > > mm_markExclusive, set the exclusive owner > > MESI_Two_Level-dir.sm:160: Warning: Non-void return ignored, return > > type is 'bool' > > MESI_Two_Level-dir.sm:294: Warning: Non-void return ignored, return > > type is 'Tick' > > MESI_Two_Level-dir.sm:298: Warning: Non-void return ignored, return > > type is 'Tick' > > MESI_Two_Level-dir.sm:302: Warning: Non-void return ignored, return > > type is 'Tick' > > MESI_Two_Level-dir.sm:348: Warning: Non-void return ignored, return > > type is 'Tick' > > MESI_Two_Level-dir.sm:351: Warning: Unused action: > > p_popIncomingDMARequestQueue, Pop incoming DMA queue > > MESI_Two_Level-dma.sm:189: Warning: Non-void return ignored, return > > type is 'Tick' > > MESI_Two_Level-dma.sm:193: Warning: Non-void return ignored, return > > type is 'Tick' > > > > Any idea why those happened? Any response or hints are appreciated! > > That looks to me like something coming from ruby, and that parser may be > quite distinct from the one in g++. But I don't use ruby so I don't > really know ... Sorry - EM > _______________________________________________ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-leave@gem5.org >