Thomas Orgis

getcpuflags_arm.c: static sigjmp_buf makes concurrent mpg123_new() crash on aarch64

Note https://www.arm.com/architecture/cpu/r-profile … mentions „optional Arm Neon technology, “ on AArch64. Seems that we have to move to OS api and guesswork? Messing with signal handlers really, really won't work in a multithreaded host application.

Oh, fuck. Yeah, I said it. Once you are in a multithreaded environment, the very idea of messing around with a signal handler triggered by the possibly illegal instruction is very, very bad. This is not what I intended with libmpg123 and also the move to get rid of mpg123_init(), which used to do something and is a no-op nowadays. Were this functions still part of the active API and clients expected to call it once before doing concurrent work, it could settle the CPU flags once in a safe context....

Oh, dear … 9 years ago. Somehow this slipped away. Are you still there, perhaps, using the conplay script?

Are you still stuck on the syntax issue for ARM64 and MSASM? Is that underdocumented? I'll have to do another bugfix release of mpg123 due to issues LAME dev found. But also would like to get this stuff in a feature release soon after. I guess I'll have to just be thankful for your time and work and take the converted asm, maybe with the conversion script also at least archived in the repo.

Well, one needs to read further on the man page, but there is, since a loooong time: -@ file, --list file Read filenames and/or URLs of MPEG audio streams from the specified file in addition to the ones specified on the command line (if any). Note that file can be either an ordinary file, a dash ``-'' to indicate that a list of filenames/URLs is to be read from the standard input, or an URL pointing to a an appropriate list file. Note: only one -@ option can be used (if more than one is specified,...

OK, thanks. I'll try to remember _WIN32 as the thing to use. I'll need some time to verify the asm stuff, including the mangle.h changes. Since it's been decades of glueing stuff on top of initial creations of the elders, I'm very conservative and want to be sure we don't miss any corner case. At the same time, I have little time available for the task … but we'll get there, eventually. How far are you with ARM64 on MSVC? Also, to get a bit outside the box: The motivation of changing sources at all...

Ah, these make more sense inside compat.h, no? #ifdef HAVE_UNISTD_H #include <unistd.h> #else // Again unsure … _WIN32 or WIN32? #ifdef WIN32 #define STDERR_FILENO _fileno(stderr) #define STDOUT_FILENO _fileno(stdout) #define STDIN_FILENO _fileno(stdin) #endif #endif Like that? Could add a branch for the default 0, 1, 2 values, too, for other platforms.