From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!yy9MKEJN2ULhWGfnfq4v5w.user.gioia.aioe.org.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: rr (was: Re: Alternative for Gnat Studio) Date: Tue, 02 Mar 2021 09:13:23 +0000 Organization: Aioe.org NNTP Server Message-ID: References: <602e608e$0$27680$e4fe514c@news.kpn.nl> <60379b69$0$20345$e4fe514c@news.kpn.nl> <86zgzn4xcs.fsf@stephe-leake.org> <5b0c7577-7dcc-468b-a24b-7447a8e796b7n@googlegroups.com> <3808e6ec-1a49-4514-84e7-f444d94cdb2cn@googlegroups.com> NNTP-Posting-Host: yy9MKEJN2ULhWGfnfq4v5w.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin) X-Notice: Filtered by postfilter v. 0.9.2 Cancel-Lock: sha1:fPQFlDeDHtgKrbjipAThPCVBujs= Xref: reader02.eternal-september.org comp.lang.ada:61460 List-Id: Emmanuel Briot 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