Re: Possible XInput2 cursor bug ?

[Eli Zaretskii]

> Date: Sun, 12 Dec 2021 20:25:02 +0530 (IST)
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> From: Madhu <enometh@meer.net>
> 
> > Maybe you should tell GDB not to read symbols automatically from the
> > shared libraries loaded by Emacs:
> >
> >   (gdb) set auto-solib-add off
> 
> That helps a lot. (It brings down the RES reported in top to 2.5G in
> jit builds, I may be misinterpreting what I'm seeing but a non-native
> build shows only some 100M in use by gdb)

On my system, debugging a natively-compiled Emacs takes GDB just a bit
more that debugging non-native one: 120MB vs 100MB.  The first number
is similar to yours, so I wonder how come the second number is so much
different on you're system.  Is that with "emacs -Q" run under a
debugger?  In any case, a full Emacs version running for 10 days under
GDB causes GDB to have just 200MB of memory here, which is a far cry
from your 2.5GB.  I wonder why such a large difference.

> >> and a new fingerprint on every `make' makes jit infeasible during
> >> "development".
> >
> > I don't understand this part.  Can you elaborate?
> 
> Like when I updated master to check the fix, the ELN files had to be
> generated again because it's a new emacs. And master is going to be
> shortlived and require a new fingerprint very shortly.

Yes, but regenerating the *.eln files takes a few minutes, so why is
that such a big problem?

> But I hit another problem. When I edited xterm.c and hit `make' emacs
> was  built but is not able to run, I got a
> 
> emacs: Trying to load incoherent dumped eln file 
> /12/build/emacs/build-xt/native-lisp/29.0.50-473a9dd2/preloaded/subr-13adf6a6-a6425de0.eln

Look closer at the build process, something probably failed there, so
the build didn't complete successfully.