Linking fails on x86 about rust64 HOT 15 CLOSED

Doesn't happen on a different system so it seems it's not your bug :)

from rust64.

@petevine This is caused by my code in minifb. It seems it fails to compile/link the C code for some reason but I'm not sure why. That being said I'm moving over all code to Rust right now so I hope with the new version issues like this will go away.

from rust64.

I think I've found the culprit - -flto among the CFLAGS which causes the static link to fail.
On my other partition I'd already been using -ffat-lto-objects to deal with such situations but didn't put 2&2 together right away.

from rust64.

I see. Is this some global flags you had set? I don't set any CFLAGS directly in the build scripts.

from rust64.

That's right, a system-wide set of custom flags.

from rust64.

Alright, that makes sense.

from rust64.

Hey, I've just tried it out on x86 Linux - the debug screen is a nice addition but does it have to use 100% CPU?

I can't remember the basic screen doing that a few months ago. (it does now after closing the other window)

from rust64.

Does it take 100% only when you close the debug window or does it take that all the time?

from rust64.

It takes 100% immediately and closing the debug window doesn't help.

from rust64.

Alright. This is usually caused when one run a program in full speed all the time. One way to solve this is to add some sleep time so it doesn't try to eat all CPU cycles

from rust64.

Yeah, here's an example trace:

Program received signal SIGSTOP, Stopped (signal).
0xb7fd978b in __vdso_clock_gettime ()
(gdb) bt
#0  0xb7fd978b in __vdso_clock_gettime ()
#1  0xb7de6055 in clock_gettime () from /lib/libc.so.6
#2  0x80015d35 in precise_time_ns::h21f17b5dea48f11abCc ()
#3  0x80015d75 in precise_time_s::h85e4ca901f51b971hCc ()
#4  0x80007b8f in c64::C64::run::h3e95dbf67108a551Hbf ()
#5  0x80006bae in main::hb0cb066ba5501602hPf ()
#6  0x80024baf in panic::recover::h12091835847439124822 ()
#7  0x80024804 in rt::lang_start::hbe64a3517224679e0iy ()
#8  0x8000a56e in main ()

from rust64.

Yeah this is something that should be added on the application level. I don't want to add it inside the minifb lib and it's just a few lines of code to do in the main loop.

from rust64.

@petevine have you observed that on Windows as well? I just checked and I top at 13% usage with the debugger open and 10-11% when it's closed. There's no explicit sleep done anywhere, there is however a clock struct that times the emulation at proper C64 speed, see src/c64/clock.rs and the tick() function. So yes, essentially the program is running at full speed albeit with small pauses between updates.

The major problem I'm experiencing in this emulator is that calling window::update() each frame causes the program to become unusuable (it takes almost 20 minutes for the emulated cpu to boot!). This is not, however, an issue with minifb or rendering itself - I only checked it briefly but it seems to be related to calling the winapi functions. I've experienced that problem with SDL2 as well (which was my main reason I switched to minifb thinking that it was related to a faulty library). Daniel and I suspect it could be a problem with code generation, since currently even declaring a large (1000+ elements) static array on the start of each update loop causes the program to slow down noticebly. I'm not sure if this is caused by something in my code or the compiler since I haven't investigated that problem thoroughly yet.

from rust64.

A quick update: I checked and added a time::sleep on start of each frame with a 1ns duration - same problem as with windows::update() being called each frame. Even though the docs say that the sleep duration may be longer than declared it still doesn't make sense for the entire program to boot that long - even if it's just the CPU being updated!

from rust64.

I have now created a separate issue for this, so if you want to discuss further let's move it to the other thread.

from rust64.