Description
I'm getting the following crash when running quite a few of our tests using cocotb (with a debug build of nvc):
> nvc \
--work=work \
--std=08 \
--map=unisim:/nix/store/1ip0gr0k3dxr8ng3jwip11k21x43r8lw-nvc-unisim-2022.2/unisim.08 \
--map=XPM:/nix/store/rmk60wqlzb3k9qpyr7510fms7prxcsw9-nvc-xpm_vhdl-unknown/xpm.08 \
-M 128m \
-H 128m \
--vhpi-debug \
--vhpi-trace \
-e muxnnwhole \
--no-save \
--jit \
-gSOME_GENERIC1=9 \
-gSOME_GENERIC2=128 \
-gSOME_GENERIC3=1024 \
-gSOME_GENERIC4=3 \
-gSOME_GENERIC5=18 \
-gSOME_GENERIC6=7 \
-r \
--ieee-warnings=off \
--dump-arrays=64 \
--vhpi-debug \
--vhpi-trace-V \
--wave=../../wave.ghw \
-g \
--load=/nix/store/bim3ncd8m0jvx2awqpi76sgq325akzcd-python3.12-cocotb-1.9.2/lib/python3.12/site-packages/cocotb/libs/libcocotbvhpi_nvc.so
** Fatal: (init): invalid type kind T_ARRAY in range_of
[0x4ba8b7] ../src/diag.c:1054 diag_femit
[0x4ba9ad] ../src/diag.c:1078 diag_emit
[0x413a33] ../src/util.c:610 fatal_trace
[0x4703f8] ../src/common.c:994 range_of
[0x4703ab] ../src/common.c:975 range_of
[0x48485d] ../src/lower.c:2710 lower_get_type_bounds
[0x4849c7] ../src/lower.c:516 lower_array_len
[0x48813c] ../src/lower.c:580 lower_array_total_len
[0x48d76d] ../src/lower.c:5402 lower_default_value
[0x48dd2f] ../src/lower.c:9789 lower_type_bounds_var
[0x499155] ../src/lower.c:9904 lower_decl
[0x4992c1] ../src/lower.c:10058 lower_decls
[0x49994d] ../src/lower.c:12930 lower_pack_body
[0x481a3c] ../src/lower.c:13518 unit_registry_get
[0x4caa4b] ../src/jit/jit-core.c:433 jit_fill_irbuf
[0x4db346] ../src/jit/jit-interp.c:1069 jit_interp
[0x4da09e] ../src/jit/jit-interp.c:639 interp_call
[0x4db12c] ../src/jit/jit-interp.c:969 interp_loop
[0x4db416] ../src/jit/jit-interp.c:1102 jit_interp
[0x4c9b34] ../src/jit/jit-core.c:692 jit_try_vcall
[0x4ca190] ../src/jit/jit-core.c:791 jit_fastcall
[0x502596] ../src/rt/model.c:769 create_scope
[0x461ebb] ../src/elab.c:1349 elab_lower
[0x465e66] ../src/elab.c:1460 elab_architecture
[0x4669d2] ../src/elab.c:2207 elab_vhdl_root_cb
[0x503674] ../src/rt/model.c:3791 call_with_model
[0x466bf1] ../src/elab.c:2261 elab
[0x40e8cc] ../src/nvc.c:524 elaborate
[0x40e1ce] ../src/nvc.c:2270 process_command
[0x410b6a] ../src/nvc.c:2430 main
nvc 1.16-devel (Using LLVM 19.1.6) [x86_64-pc-linux-gnu]
Please report this bug at https://github.com/nickg/nvc/issuesThere's no context given so I'm not sure where to begin in tracking down where the problem might be in our code. It looks like similar problems have been reported in #953, #906, #842, #830, #750, and a few others. I can't seem to find any way to get any debugging info out of NVC to help me track down where things are going wrong so I don't know where to start in coming up with a test case. After spending a bit of time in LLDB trying to see if I could trace where in our code the error came from, the only things that seems potentially useful is the following definitions:
type InterlacedSignal is record
Data : ArrayOfSigned;
Valid : std_logic;
end record;
subtype Interlaced16bSignal is InterlacedSignal(Data(open)(15 downto 0));
type SignedSignal is record
Data : signed;
Valid : std_logic;
end record;
subtype Signed16bSignal is SignedSignal(Data(15 downto 0));(found by looking at loc values in the debugger and seeing what
My reasoning for thinking this is relevant is it's hitting the following code in range_of:
case C_OPEN:
return range_of(type_base(type), dim);which is then calling range_of with type as
The contents of type for the parent call are:
While looking at this in the debugger, it looks like there's actually a lot of location information available in many of the calls above, but I don't know how to translate them into actual files. I'm wondering how hard it would be to add this information to the stack trace that's printed when it's available... probably not trivial, but it could help a lot in debugging things (for users and nvc devs).
Full call stack with file locations in current master for completeness: