We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1398 - multiple issues in SDL_cpuinfo.c on x86_64-sun-solaris2.10
Summary: multiple issues in SDL_cpuinfo.c on x86_64-sun-solaris2.10
Status: RESOLVED ENDOFLIFE
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: 1.2.15
Hardware: x86_64 Solaris
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-25 10:55 UTC by Tim Mooney
Modified: 2015-08-25 09:38 UTC (History)
1 user (show)

See Also:


Attachments
fix missing ); in solaris asm block & split 64 bit off into a separate block (2.45 KB, patch)
2012-01-25 10:55 UTC, Tim Mooney
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Mooney 2012-01-25 10:55:27 UTC
Created attachment 807 [details]
fix missing ); in solaris asm block & split 64 bit off into a separate block

I'm building SDL-1.2.15 on x86_64-sun-solaris2.10 with the Oracle Studio 12.2 compiler suite and the standard Solaris 10u8 linker & assembler.  I currently have SDL 1.2.9 installed, but that version predates most of the assembly (at least for Solaris & !gcc) in SDL_cpuinfo.c.

I've run into a couple issues with SDL_cpuinfo.c.

1) There's a syntax error in CPU_getCPUIDFeatures because the #elif case
for Solaris x86/x86_64 doesn't have the closing ) for the __asm( block:

"./src/cpuinfo/SDL_cpuinfo.c", line 223: syntax error before or at: return
cc: acomp failed for ./src/cpuinfo/SDL_cpuinfo.c

That's an easy fix, just add the ');' on line 221, before the closing #endif.
Once I do that, though, the real problems start:

/bin/bash ./libtool --mode=compile cc -Xa -xO3 -KPIC -mt -xtarget=native -m64 -xarch=native -I/local/include  -I/local/include -I./include -D_GNU_SOURCE=1  -I/usr/openwin/include -DXTHREADS -D_REENTRANT -c ./src/cpuinfo/SDL_cpuinfo.c  -o build/SDL_cpuinfo.lo
libtool: compile:  cc -Xa -xO3 -KPIC -mt -xtarget=native -m64 -xarch=native -I/local/include -I/local/include -I./include -D_GNU_SOURCE=1 -I/usr/openwin/include -DXTHREADS -D_REENTRANT -c ./src/cpuinfo/SDL_cpuinfo.c  -KPIC -DPIC -o build/.libs/SDL_cpuinfo.o
Assembler: SDL_cpuinfo.c
        "/tmp/ube.1327515185.2736.06.s", line 464 : Illegal mnemonic
        Near line: "        pushl   %ebx              "
        "/tmp/ube.1327515185.2736.06.s", line 466 : Illegal mnemonic
        Near line: "        popl    %ebx              "
        "/tmp/ube.1327515185.2736.06.s", line 471 : Illegal mnemonic
        Near line: "        pushl   %ebx              "
        "/tmp/ube.1327515185.2736.06.s", line 473 : Illegal mnemonic
        Near line: "        popl    %ebx              "
        "/tmp/ube.1327515185.2736.06.s", line 722 : Illegal mnemonic
        Near line: "        pushl   %ebx             "
        "/tmp/ube.1327515185.2736.06.s", line 724 : Illegal mnemonic
        Near line: "        popl    %ebx             "
        "/tmp/ube.1327515185.2736.06.s", line 728 : Illegal mnemonic
        Near line: "        pushl   %ebx             "
        "/tmp/ube.1327515185.2736.06.s", line 730 : Illegal mnemonic
        Near line: "        popl    %ebx             "
cc: fbe failed for ./src/cpuinfo/SDL_cpuinfo.c


In every case, it's complaining about either pushl or popl.  Based on what I see examining the asm block for gcc & x86_64, I'm guessing that the problem is that I'm in 64 bit mode (not 32 bit) and those pushl/popl should be pushq/popq.
The gcc x86_64 case also uses a different register.

Following the gcc & x86_64 example, if I split the #elif into two (one for 32 bit mode and one for 64 bit mode) and change "pushl %ebx" to "pushq %rbx" and
"popl %ebx" to "popl %rbx" in the 64 bit code, the compilation will proceed.
I don't know enough about x86 assembly on Solaris to know if the register change was the right thing to do.

If I install the library and then build the test suite and run testplatform, it reports that it does NOT detect any of the available CPU features, so something still isn't quite right with the feature detection code.

The patch to get it to compile is attached, if you have further suggestions for things to try to get the routines to actually report the CPU features, I would be happy to dig a little deeper.
Comment 1 Ryan C. Gordon 2015-08-25 09:38:21 UTC
Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we _will_ accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email (icculus@icculus.org) and we'll try to find some way to help you out of your situation.

Thank you,
--ryan.