Rti field of processes (of type Grt.Processes.Process_Type) is not correctly populated.

[tfuto]

Description
--disp-sensitivity returns garbage, as the Rti field of processes (of type Grt.Processes.Process_Type) is not correctly populated. E.g. console shows:

.test(beh).a
  wakeup ???
  driven ???
.test(beh).b
  wakeup ???
  driven ???

even though --dump-rti shows correct RTI information.

If you use the test.vhd provided, and do these actions:

ghdl_mcode -a test.vhd
ghdl_mcode -e test
gdb --args ghdl_mcode -r test --disp-sensitivity --dump-rti
(gdb) b grt-disp_signals.adb:364
(gdb) r

GDB shows:

(gdb) p Action.Proc.Rti
$1 = (base => (system.address) 0x0, block => 0x0)

Later, Action.Proc.Rti is directly written to stdout at grt-disp_signals.adb#L365

procedure Disp_Scalar_Sensitivity (...)
...
  Put (stdout, Grt.Processes.Get_Rti_Context (Action.Proc));
...

Expected behaviour
Correctly displaying sensitivity information.

How to reproduce?

------------------------------------
-- Generate some signal activity.
------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;

entity test is
end entity;

architecture beh of test is
  signal a : std_logic;
  signal b : std_logic;
  signal c : std_logic;
  signal d : std_logic;
  
begin

  P1 : process (a) is
  begin
    b <= not a;
  end process P1;

  P2 : process (b, c) is
  begin
    d <= b or c;
  end process P2;
  
  TB: process 
  begin
    a <= '1';
    c <= '0';
    wait for 10 ns;
    a <= '0';
    wait;
  end process TB;

end architecture beh;

ghdl -a test.vhd
ghdl --elab-run test --disp-sensitivity

Context
Please, provide the following information:

• OS: Ubuntu 22.04.3 LTS
• Origin: Built from sources: commit 7b53bcba15ff4a56d31373d7c39085fb099e337a

Additional context

$ build/ghdl_mcode -v
GHDL 4.0.0-dev (tarball) [Dunoon edition]
 Compiled with GNAT Version: 13.2.0
 static elaboration, mcode code generator

[tgingold]

Yes, RTI are not fully populated with mcode; but probably RTI will disappear.
Are you really interested in viewing the sensitivities ?

[tfuto]

@tgingold Well, there are several considerations (I am not familiar with the detailed roadmap of GHDL):

• As a pure VHDL coder, I don't need the RTI.
• As a (potential) contributor/porter to the GHDL codebase, I very much need the RTI. I am reading through an insane amount of Ada code, and RTI helps understanding what is happening, and why that is happening. There is always scarcity of good documentation, and there is no better and verbose "documentation" than printing RTI data on the spot, in an useful format. This also reduces learning curve and saves a lot of communication that eventually does not get recorded in a shared knowledge base.
• As a code debugger, it is great to just call a function that shows the current detailed internal state, instead of tracking pointers manually and figuring out what is going on.
• As an educator/teacher, the more RTI information I have and can show, the better. Mcode is pretty much the way to show internal operation inside GPS, without getting involved with further intricacies of other back-ends.

Also, the contract exists in the source code (a CLI option) and it is not fulfilled, and so that is why I reported this as a bug.

I found this issue actually during a GDB debugging session (GDB crashed on printing a value - I mean GDB itself crashed on a GDB code bug with a fatal error), and I said: "Hey! We have this nice function Disp_All_Sensitivity, so that I don't have to trace manually what is going on with sensitivities!" Little did I know. 😄

Also, if you ever plan to implement native GDB debugging of VHDL (so: attaching GDB to the simulated design, not the simulator), you probably need all RTI to provide meaningful context and useful output. (I saw the -i flag in the current code base, but adding direct GDB support is probably a better direction).

[tgingold]

(Late answer)
If you use llvm or gcc backend with -g, you can somewhat debug the design: set breakpoint on lines, step and even see local variables. But that's limited. And executable generation will probably be deprecated.
There is a problem with RTIs: they don't work well with 2008 features. Is it fixable ? Maybe, but it's extra work.

If you need to display sensitivity, this could be added to the -i commands.
(And if you want to debug, you could also try -i with --interp. That's currently far from perfect)