Re: Possible XInput2 cursor bug ?

[Madhu <enometh@meer.net>]

*  Eli Zaretskii <eliz@gnu.org> <83czm1oo82.fsf@gnu.org>
Wrote on Sun, 12 Dec 2021 17:08:13 +0200
>> Date: Sun, 12 Dec 2021 20:25:02 +0530 (IST)
>> From: Madhu <enometh@meer.net>
>> 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.

yes for emacs -Q -D. I can confirm that by the time I get to the end
of the first backtrace I have 2GB rss in a native build, and about
100M RSS for a non-native build. I do have some system libraries
(glib, etc.)  compiled with debug info, but that doesn't explain the
difference.


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

It takes a little longer for me and it's wasteful if youre just going
to throw it away anyway.

>> 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.

[I couldn't spot it, but a ./configure and build fixed it after
recompiling all the c files while retaining the same eln directory (i
think)
]