Re: Native compilation on MPS branch

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: gerd.moellmann@gmail.com,  emacs-devel@gnu.org
>> Date: Thu, 25 Apr 2024 01:48:43 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Andrea Corallo <acorallo@gnu.org>
>> >> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> >> Date: Wed, 24 Apr 2024 16:54:30 -0400
>> >> 
>> >> IME rr is invaluable for debugging GC bugs, one can do things like
>> >> placing watch-points while doing reverse execution and discover
>> >> immediately where something was modified the last time.  You did a very
>> >> good job reaching this point of the development without rr.
>> >
>> > We have the last_marked[] array to facilitate debugging of GC without
>> > rr.  I hope we will be able to do something similar with MPS, because
>> > rr is not universally available (e.g., not on Windows).
>> >
>> >> Anyway I'll mention a trick I find extremely usefull to discover where
>> >> something was modified last time before a certain event without rr, I
>> >> apologize if you know it already but in case it might help some other
>> >> reader :)
>> >> 
>> >> 1 When we crash we set a watch point on the memory we see got
>> >> unexpectedly modified
>> >> 2 We set the ignore number of the watch-point to a very large number
>> >> 3 We restart the execution of the program
>> >> 4 When the program crashes again we can see how many time the watch point
>> >> was actually ignored
>> >> 5 We subtract 1 to this number and we set it again as the ignore number
>> >> of the watch-point
>> >> 6 We restart again and tada!! We are where that piece of memory was
>> >> modified for the last time :)
>> >
>> > This only works if you disable ASLR, AFAIU.
>> 
>> Correct, on GNU/Linux gdb does that by default, no idea on other
>> systems.
>
> It does it also on Windows, if the version of the OS is new enough to
> support that.

LLDB does it too on macOS.

I'm BTW one step further, in that emacs_lldb.py works unchanged with
LLVM/HEAD. So, they apparently have broken something in in 18. 

And I'm now using the fixes that Eli and Helmut made. I thought it
didn't matter to change the baseline because I got a new clang with LLVM
too, so how much more could I possibly rock the boat?

Result is that the same scenario as before (clean build, then build with
macroexp native-compiled) leads to a different outcode

Loading bindings (source)...
Loading window (source)...
Loading /Users/gerd/emacs/savannah/igc/lisp/files.el (source)...
Loading emacs-lisp/macroexp (native compiled elisp)...
Loading /Users/gerd/emacs/savannah/igc/lisp/cus-face.el (source)...
Loading /Users/gerd/emacs/savannah/igc/lisp/faces.el (source)...
Loading /Users/gerd/emacs/savannah/igc/lisp/ldefs-boot.el (source)...
Loading /Users/gerd/emacs/savannah/igc/lisp/button.el (source)...
Loading /Users/gerd/emacs/savannah/igc/lisp/emacs-lisp/cl-preloaded.el 
(source)...

./lisp.h:1777: Emacs fatal error: assertion failed: VECTORLIKEP (a)
Fatal error 6: Aborted

Just for info.