I'm trying to build melonDS outside of pkgsrc and having trouble to successfully compile the program. Was wondering if someone has any tips on how to compile packages that's not in pkgsrc? There's an older version of melonDS available in pkgsrc (0.8.3) but with the release of 0.9 comes a JIT recompiler for ARM which improves performance significantly and finally would make it possible to have smooth DS emulation e.g. on the Pinebook Pro and RockPRO64. I looked for specific NetBSD patches and configure arguments in the makefile of the current package in pkgsrc, is there some other places I should look for NetBSD specific code? Any insight would be well appreciated. Error message where I'm stuck at (same on both AArch64 and x86): Building CXX object src/CMakeFiles/core.dir/ARMJIT_Memory.cpp.o /home/x/melonDS/src/ARMJIT_Memory.cpp: In function ‘void SigsegvHandler(int, siginfo_t*, void*)’: /home/x/melonDS/src/ARMJIT_Memory.cpp:186:34: error: ‘struct mcontext_t’ has no member named ‘pc’ context->uc_mcontext.pc = (u64)desc.FaultPC; ^~ *** Error code 1 Stop. make[2]: stopped in /home/x/melonDS/build *** Error code 1 Stop. make[1]: stopped in /home/x/melonDS/build *** Error code 1 Stop. make: stopped in /home/x/melonDS/build if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); }

oui This needs more #ifdef for ARM and x86. File a bug on GitHub. As a workaround for this compile failure, you can try this: diff -urN melonDS-master.orig/src/ARMJIT_Memory.cpp melonDS-master/src/ARMJIT_Memory.cpp --- melonDS-master.orig/src/ARMJIT_Memory.cpp 2021-02-23 18:15:02.000000000 +0000 +++ melonDS-master/src/ARMJIT_Memory.cpp 2021-02-24 21:04:39.404854128 +0000 @@ -190,6 +190,8 @@ #else #ifdef __APPLE__ context->uc_mcontext->__ss.__pc = (u64)desc.FaultPC; + #elif defined(__NetBSD__) + _UC_MACHINE_SET_PC(context, (u64)desc.FaultPC); #else context->uc_mcontext.pc = (u64)desc.FaultPC; #endif if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); }

The reason I stopped updating the package is that they added some dependencies on Linux-only system calls. Good luck, I think.

nia It's sad to hear open source projects going the Linux-only route.. Even if not fully functional, I'll try to see how far I can go with this.

Compiling melonDS

rvp

oui Thanks for the quick patch! This fixes the error on both ARM and x86

You shouldn't have needed that patch at all: They should've just used the *context(2) functions, or, at least, the macros defined in ucontext.h like I did. In any case, switching contexts like this very 1980s. Why aren't they using pthreads here for this I wonder--performance maybe?

oui The next error I'm stuck at is the linking process:

Doesn't tell me much. Make cmake print out the commands it is running. Pass --verbose and/or --log-level=VERBOSE.

rvp cmake writes logs to the build directory by default. @oui look inside the build directory for the build log.

oui

I managed to successfully compile melonDS. Turns out the default gcc version in NetBSD's comp set was too old, compiling with clang or gcc10 from pkgsrc fixed the problem.

It runs just fine with default settings. However, the sole reason I wanted to build the latest melonDS was to try out the new JIT recompiler for ARM - and surprise surprise, enabling the JIT recompiler aborts with a core dump. Anticlimactic, SAD.

nia

Does it need paxctl +m on the binary?

oui

Thank you @nia! paxctl +m on the binary fixed the core dump.

Patches for NetBSD ARM64 just got fixed upstream in the fastmem-pc branch.

Everything finally works now.

Unfortunately however, the performance was a let down. The JIT recompiler is supposed to drastically increase the performance, but I was barely able to tell the difference with JIT enabled. As it stands now, the performance is unplayable on Pinebook Pro and RockPRO64.

I tested on Linux as well on the Pinebook Pro and the performance with JIT enabled was night and day; from unplayable to almost butter smooth experience - maybe this has something to do with the Linux-only system calls nia mentioned?

rvp

oui I tested on Linux as well on the Pinebook Pro and the performance with JIT enabled was night and day; from unplayable to almost butter smooth experience

Is JIT even enabled in NetBSD+ARM?

oui

Thanks again @nia! I can confirm that compiling with the default gcc version on NetBSD 9.1 works just fine now.

rvp Is JIT even enabled in NetBSD+ARM?

I believe so, there also seems to be some strange behavior with the performance on x86.

I have been testing melonDS with different emulator settings, nda roms and different compilers to try to figure out more about the bad performance (low frame rate, stuttering and audio distortion etc):

ARM64
gcc 7.5 - minor graphical glitches
clang 10.0.1 - a lot of graphical glitches with lines across screen.
gcc10 - almost 0 graphical glitches (not noticeable unless you really try to find them)

Difference in compiler did not affect frame rate, I was able to squeeze a few extra fps by tweaking JIT block size and changing value of hw.audio0.blk_ms with sysctl as suggested by nia.
These are very small performance tweaks, the play experience is not enjoyable but it's now at least at a playable frame rate in comparison to the older melonDS version in pkgsrc.

x86
Same glitches depending on which compiler is used as mentioned above on ARM64.

However, the strange thing is that performance with JIT enabled is about the same (overall smooth frame rate with occasional stuttering) as the older melonDS version already available in pkgsrc that doesn't have JIT supported. Turning off JIT I would expect the same performance as the older melonDS but it performs slightly worse with more audio stuttering and occasional frame drops.

EDIT:
My tests seemed to be case specific on heavy 3D rendered scenes, the overall performance across different games is better (just by a little bit) with or without JIT enabled on the newly compiled melonDS on x86.

nia

Turns out the default gcc version in NetBSD's comp set was too old, compiling with clang or gcc10 from pkgsrc fixed the problem.

Nope! It's new enough. It just doesn't support ENABLE_LTO=ON.

https://github.com/Arisotura/melonDS/pull/1018

It looks like they've rewritten the problematic code, so I should be able to look into updating the package...

rvp

nia Nope! It's new enough. It just doesn't support ENABLE_LTO=ON.

~~-flto just doesn't work for static libraries on any of the BSDs. I always have to remove that flag if the stuff I compile (using either Clang or GCC) builds static libraries (eg. Lynx, ncurses).~~

-flto works on the BSDs, but, is slightly fiddly to get LTO working on all of them.

nia

The difference between compilers sounds like there's undefined behavior somewhere

oui

nia I didn't test thoroughly enough for x86, turns out x86 has the exact same glitches as well depending on which compiler was used.

rvp

rvp Well, -flto works with static libraries if you pass --plugin /usr/libexec/liblto_plugin.so to ar and friends.
And, poking around, I see that there is a wrapper to do this (/usr/src/external/gpl3/gcc/dist/gcc/gcc-ar.c), but, this is neither compiled nor installed on 9.1_STABLE.

Makefile:

AR= ar --plugin /usr/libexec/liblto_plugin.so
RANLIB= ranlib --plugin /usr/libexec/liblto_plugin.so
CFLAGS= -Wall -Wconversion -Wextra -O2 -D_FORTIFY_SOURCE=2 -fstack-protector-all
CFLAGS+= -flto -fpie -march=native -pipe
LDFLAGS= -fuse-linker-plugin -pie -s
CFLAGS+= -I.
LDFLAGS+= -L.

main: main.o libfoo.a
	${CC} ${CFLAGS} ${LDFLAGS} -o $@ main.o -lfoo

libfoo.a: foo.o bar.o
	${AR} -rc $@ $>
	${RANLIB} $@

main.o:
foo.o: foo.h
bar.o: bar.h

clean:
	rm -f main libfoo.a *.o

main.c:

#include "foo.h"
int main(void) {
	foo("hello world");
	return 0;
}

foo.c:

#include "bar.h"
void foo(char* s) {
	bar(s);
}

foo.h:

void foo(char* s);

bar.c:

#include <stdio.h>
void bar(char* s) {
	printf("%s\n", s);
}

bar.h:

void bar(char* s);