rr (was: Re: Alternative for Gnat Studio)

[Simon Wright <simon@pushface.org>]

Emmanuel Briot <briot.emmanuel@gmail.com> writes:

> Do you know about the "catch exception" command ? gdb will
> automatically break when an exception is raised. There could be a lot
> of these, so you can also try the variant "catch exception unhandled".
> This doesn't always help to investigate what happened just before an
> exception, so we have also started using the "rr" tool, which
> basically executes your program and records everything at every step,
> so that you can replay it. There is a cost in performance of course,
> but not as big as one would expect.

It's a shame (but not surprising!) that this is Linux-only.

It'd probably really help with my current problem, where GCC 11.0.0 and
GNAT CE 2020 arm-eabi throw an ICE when compiling a generalised
iteration with my Cortex GNAT RTS (no problem compiling against an
AdaCore RTS). Building the compiler with debugging, OK-ish (CFLAGS='-g
-O0'). Finding the exact invocation of gcc, OK (gprbuild -v
--keep-temp-files). Calling that invocation and getting GDB to start
with the actual gnat1 call, OK (add -wrapper gdb,--args to the gcc
command). Setting a break on the place where the ICE is raised, OK (b
sem_ch8.adb:5490). But then you've got a lengthy traceback, at some
point in which the compiler was misled by something in my runtime to
construct something wrongly.

There are definitely runtime-related aspects to the analysis: f.e. in
Exp_Ch6.Add_Task_Actuals_To_Build_In_Place_Call, there's a line (:596
here)

      --  Use a dummy _master actual in case of No_Task_Hierarchy

      if Restriction_Active (No_Task_Hierarchy) then
         Actual := New_Occurrence_Of (RTE (RE_Library_Task_Level), Loc);

Someone familiar with the compiler internals, and how to explore them in
the debugger, would no doubt find what's wrong in a flash, but I doubt
that posting on the GCC Bugzilla would get a speedy response!

https://github.com/rr-debugger/rr