openhwgroup / core-v-verif

Functional verification project for the CORE-V family of RISC-V cores.
https://docs.openhwgroup.org/projects/core-v-verif/en/latest/index.html
Other
455 stars 224 forks source link

core-v-verif testbench is leaving many files in /tmp and not cleaning up on termination #2270

Open eroom1966 opened 1 year ago

eroom1966 commented 1 year ago

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

MikeOpenHWGroup commented 1 year ago

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.

eroom1966 commented 1 year ago

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

MikeOpenHWGroup commented 1 year ago

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.

pascalgouedo commented 1 year ago

Hi @LeeHoff @MikeOpenHWGroup

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.

eroom1966 commented 1 year ago

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