core-v-verif testbench is leaving many files in /tmp and not cleaning up on termination
eroom1966 opened this issue · comments
It appears that running the core-v-verif simulation, especially the full suite of tests is creating hundreds of temporary files in /tmp and not cleaning up on exit. An example of how to reproduce is as follows (based upon cv32e40s)
make clean_all
make sanity CV_CORE=cv32e40s
in my environment this resulted in the following files created and left in /tmp, (YMMV)
-rw------- 1 moore users 265 Nov 1 14:11 tmpwcmwdct4
-rw------- 1 moore users 3467 Nov 1 14:11 tmp4jvohs49
-rw------- 1 moore users 265 Nov 1 14:12 tmpdauke327
-rw------- 1 moore users 3467 Nov 1 14:12 tmp1dvw9oco
tmpwcmwdct4 tmpdauke327 have equivalent content
tmp4jvohs49 tmp1dvw9oco have equivalent content
$ cat tmpwcmwdct4
TEST_DESCRIPTION=Simple hello-world sanity test
TEST_NAME=hello-world
TEST_PROGRAM=hello-world
TEST_TEST_DIR=/home/moore/git/eroom1966/openhwgroup/cv32e40s-dev/cv32e40s_dev/cv32e40s/tests/programs/custom/hello-world
TEST_UVM_TEST=uvmt_$(CV_CORE_LC)_firmware_test_c
$ cat tmp4jvohs49
CFG_CFLAGS=-Wl,--nmagic
CFG_COMPILE_FLAGS=+define+ZBA_ZBB_ZBC_ZBS
CFG_CV_SW_MARCH=rv32im_zba1p00_zbb1p00_zbc1p00_zbs1p00_zicsr_zca_zcb_zcmp_zcmt_zifencei
CFG_DESCRIPTION=Default configuration for CV32E40S simulations
CFG_NAME=default
CFG_OVPSIM=--override cpu/envcfg_mask=0x0 --override cpu/PMP_initialparams=T --override cpu/PMP_maskparams=T --override cpu/hpmcounter_undefined=T --override cpu/PMP_registers=64 --override cpu/PMP_grain=0 --override cpu/mask_pmpaddr0=0x00000000 --override cpu/mask_pmpaddr1=0x00000000 --override cpu/mask_pmpaddr2=0x00000000 --override cpu/mask_pmpaddr3=0x00000000 --override cpu/mask_pmpaddr4=0x00000000 --override cpu/mask_pmpaddr5=0x00000000 --override cpu/mask_pmpaddr6=0x00000000 --override cpu/mask_pmpaddr7=0x00000000 --override cpu/mask_pmpaddr8=0x00000000 --override cpu/mask_pmpaddr9=0x00000000 --override cpu/mask_pmpaddr10=0x00000000 --override cpu/mask_pmpaddr11=0x00000000 --override cpu/mask_pmpaddr12=0x00000000 --override cpu/mask_pmpaddr13=0x00000000 --override cpu/mask_pmpaddr14=0x00000000 --override cpu/mask_pmpaddr15=0x00000000 --override cpu/mask_pmpaddr16=0x00000000 --override cpu/mask_pmpaddr17=0x00000000 --override cpu/mask_pmpaddr18=0x00000000 --override cpu/mask_pmpaddr19=0x00000000 --override cpu/mask_pmpaddr20=0x00000000 --override cpu/mask_pmpaddr21=0x00000000 --override cpu/mask_pmpaddr22=0x00000000 --override cpu/mask_pmpaddr23=0x00000000 --override cpu/mask_pmpaddr24=0x00000000 --override cpu/mask_pmpaddr25=0x00000000 --override cpu/mask_pmpaddr26=0x00000000 --override cpu/mask_pmpaddr27=0x00000000 --override cpu/mask_pmpaddr28=0x00000000 --override cpu/mask_pmpaddr29=0x00000000 --override cpu/mask_pmpaddr30=0x00000000 --override cpu/mask_pmpaddr31=0x00000000 --override cpu/mask_pmpaddr32=0x00000000 --override cpu/mask_pmpaddr33=0x00000000 --override cpu/mask_pmpaddr34=0x00000000 --override cpu/mask_pmpaddr35=0x00000000 --override cpu/mask_pmpaddr36=0x00000000 --override cpu/mask_pmpaddr37=0x00000000 --override cpu/mask_pmpaddr38=0x00000000 --override cpu/mask_pmpaddr39=0x00000000 --override cpu/mask_pmpaddr40=0x00000000 --override cpu/mask_pmpaddr41=0x00000000 --override cpu/mask_pmpaddr42=0x00000000 --override cpu/mask_pmpaddr43=0x00000000 --override cpu/mask_pmpaddr44=0x00000000 --override cpu/mask_pmpaddr45=0x00000000 --override cpu/mask_pmpaddr46=0x00000000 --override cpu/mask_pmpaddr47=0x00000000 --override cpu/mask_pmpaddr48=0x00000000 --override cpu/mask_pmpaddr49=0x00000000 --override cpu/mask_pmpaddr50=0x00000000 --override cpu/mask_pmpaddr51=0x00000000 --override cpu/mask_pmpaddr52=0x00000000 --override cpu/mask_pmpaddr53=0x00000000 --override cpu/mask_pmpaddr54=0x00000000 --override cpu/mask_pmpaddr55=0x00000000 --override cpu/mask_pmpaddr56=0x00000000 --override cpu/mask_pmpaddr57=0x00000000 --override cpu/mask_pmpaddr58=0x00000000 --override cpu/mask_pmpaddr59=0x00000000 --override cpu/mask_pmpaddr60=0x00000000 --override cpu/mask_pmpaddr61=0x00000000 --override cpu/mask_pmpaddr62=0x00000000 --override cpu/mask_pmpaddr63=0x00000000 #--showoverrides #--trace #--trace --tracechange --traceshowicount --monitornets
CFG_PLUSARGS=+enable_zba_extension=1 +enable_zbb_extension=1 +enable_zbc_extension=1 +enable_zbs_extension=1 +fix_sp=1 +fix_ra=1 +enable_zca_extension=1 +enable_zcb_extension=1 +enable_zcmt_extension=1 +enable_zcmp_extension=1 #+gen_wfe_wu_noise=1 #+enable_write_pmp_csr=1 #+pmp_randomize=0 #+pmp_num_regions=64 #+pmp_granularity=0
These should be cleaned up either on exit, or after usage.
I noticed in /tmp on my machine I had thousands of these files, and finally narrowed it down to running core-v-verif
Thanks for the issue @eroom1966.
The unstated assumption here is that on most Linux systems, old files in /tmp are periodically deleted. On my Ubuntu and Debian machines everything older than one week is automatically removed and on our CentOS machine everything older than a month is deleted. This out-of-the-box behavior so unless you've changed it on your system, these files should not be persistent.
I don't think you can really rely upon systems doing that TBH
if the infrastructure is creating temporary files, it should really clean then up after usage - unless there is some crash in which case the cleanup routines may not execute.
I also see xcelium creating many temporary files, but these are all reaped at the end of the execution
where in the code is the request made for these temporary files ?
it should not be too difficult to work out the expected lifetime of these files
where in the code is the request made for these temporary files ?
The scripts that generates the tmp-files are bin/yaml2make and bin/cfgyaml2make. These scripts are launched by the makefiles, specifically mk/Common.mk, and are not intended to be run by the user. A brief description of their operation is included in mk/TOOLCHAIN.md.
I don't really like those tmp/hidden files either.
As they are included by makefiles after creation, sometimes it happens that you need to look at them to understand if they are correctly generated. So you have to hack makefiles to report tmp filename to be able to look at them.
I would really prefer them to be generated in $(SIM_RUN_RESULTS) like it is done for ovpsim.ic
Nothing hidden any more...
Then you can have a look to them if needed and they are destroyed like any other simulation generated stuff when you remove $(SIM_RUN_RESULTS).
Cheers,
Pascal.
Hi Pascal
I was coming to the same conclusion
Yesterday I spent a lot of time, trying to define these /tmp/tmpxxxx files us .INTERMEDIATE files in the Makefile
Usually gmake will remove files flagged as intermediate, but could not get this to work
Following this I was coming to the same conclusion you mention, which is that these files should go into the $(SIM_RUN_RESULTS) area
volunteers to implement ..... ?
Thx
Lee