Hi all,
I have spent a lot of time trying to compile SDL (v1.2.8 and the latest of CVS) in a new system with GNU GCC 3.4 and I was very close to became crazy… there werent any compilitation error…but… there are a lot of problem at runtime (most of them with my own inline assembly code).
After long troubleshooting I compiled with old GCC 3.3 and everything started to work successfully… so I looked for something on google and I found this:
http://mail-index.netbsd.org/pkgsrc-bugs/2004/06/07/0003.html
When this patch will be integrated with CVS? I think is very important patch.
I think this could be asked on a GNU forum but… maybe here…anyone knows where I can find more information about that bugs? because I have a lot of inline assembly and it failed! I imagine that I only have to add a push ebx and pop ebx…
Thanks in advance
Roberto Prieto
megastorm at mi.madritel.es
http://www.megastormsystems.com
It appears a slightly different version of that patch has already been
applied to CVS a long time ago. For CPUID opcodes, the ebx is saved into edi
and later restored from it. The mixer code has long been changed since that
patch (since rev 1.2; the S8 mixer has another bug, but it’s worth its own
thread).
I really don’t know what the push/pop ebx is supposed to accomplish in the
patch referenced, as ebx is already saved into edi there. It seems to have
been taken from another patch and applied here in vain.
You just have to remember one of the CDECL calling convention rules: ebx,
esi, edi registers are callee-saved, so if they get clobbered in your
function the compiler has to save them and restore on return. I am no gcc
expert, but I recall gcc likes using ebx as base in relative addressing when
in PIC mode. There is probably a bug in your gcc 3.4.x that prevents it from
correctly accounting for ebx in the clobber list. The compatibility rule
seems to be here: “do not touch ebx, or save it yourself”.
Alex.________________________________
From: Roberto Prieto
Sent: Monday, September 19, 2005 12:23 PM
To: sdl at libsdl.org
Subject: [SDL] GNU GCC 3.4.x problem with inline assembly on SDL
Hi all,
I have spent a lot of time trying to compile SDL (v1.2.8 and the latest of
CVS) in a new system with GNU GCC 3.4 and I was very close to became
crazy… there werent any compilitation error…but… there are a lot of
problem at runtime (most of them with my own inline assembly code).
After long troubleshooting I compiled with old GCC 3.3 and everything
started to work successfully… so I looked for something on google and I
found this:
http://mail-index.netbsd.org/pkgsrc-bugs/2004/06/07/0003.html
When this patch will be integrated with CVS? I think is very important
patch.
I think this could be asked on a GNU forum but… maybe here…anyone knows
where I can find more information about that bugs? because I have a lot of
inline assembly and it failed! I imagine that I only have to add a push ebx
and pop ebx…
Thanks in advance
Roberto Prieto
megastorm at mi.madritel.es
http://www.megastormsystems.com
Hello Alex,
I dont use ebx on my code, so I dont store it to restore before
returning…
and the same piece of code works with GCC 3.2 & 3.3 but indeed, it does not
work with GCC 3.4…
when you said that ebx is stored on edi… do you mean that automatically
the compiler does this copy(ebx->edi)?
because it could be my problem… I have done testing and when I modified
edi… the routine fails, so Im going to
store edi. Anyway, I will see the assembly code generated by GCC 3.2 & 3.4
and check the differences.
I will be out on holidays until next week so I can not respond you but I
want to thank you for your reply.
Regards
Roberto> ----- Original Message -----
From: avcp-sdlmail@usa.net (Alex Volkov)
To: "‘A list for developers using the SDL library. (includesSDL-announce)’"
Sent: Tuesday, September 20, 2005 12:00 AM
Subject: RE: [SDL] GNU GCC 3.4.x problem with inline assembly on SDL
It appears a slightly different version of that patch has already been
applied to CVS a long time ago. For CPUID opcodes, the ebx is saved into
edi
and later restored from it. The mixer code has long been changed since
that
patch (since rev 1.2; the S8 mixer has another bug, but it’s worth its own
thread).
I really don’t know what the push/pop ebx is supposed to accomplish in the
patch referenced, as ebx is already saved into edi there. It seems to have
been taken from another patch and applied here in vain.
You just have to remember one of the CDECL calling convention rules: ebx,
esi, edi registers are callee-saved, so if they get clobbered in your
function the compiler has to save them and restore on return. I am no gcc
expert, but I recall gcc likes using ebx as base in relative addressing
when
in PIC mode. There is probably a bug in your gcc 3.4.x that prevents it
from
correctly accounting for ebx in the clobber list. The compatibility rule
seems to be here: “do not touch ebx, or save it yourself”.
Alex.
From: Roberto Prieto
Sent: Monday, September 19, 2005 12:23 PM
To: sdl at libsdl.org
Subject: [SDL] GNU GCC 3.4.x problem with inline assembly on SDL
Hi all,
I have spent a lot of time trying to compile SDL (v1.2.8 and the latest of
CVS) in a new system with GNU GCC 3.4 and I was very close to became
crazy… there werent any compilitation error…but… there are a lot of
problem at runtime (most of them with my own inline assembly code).
After long troubleshooting I compiled with old GCC 3.3 and everything
started to work successfully… so I looked for something on google and I
found this:
http://mail-index.netbsd.org/pkgsrc-bugs/2004/06/07/0003.html
When this patch will be integrated with CVS? I think is very important
patch.
I think this could be asked on a GNU forum but… maybe here…anyone
knows
where I can find more information about that bugs? because I have a lot of
inline assembly and it failed! I imagine that I only have to add a push
ebx
and pop ebx…
Thanks in advance
Roberto Prieto
megastorm at mi.madritel.es
http://www.megastormsystems.com
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Roberto Prieto wrote:
when you said that ebx is stored on edi… do you mean that
automatically the compiler does this copy(ebx->edi)?
No, I meant the particular piece of code in SDL_cpuinfo.c that executes the
CPUID instruction – manually written code. The compiler will only
save/restore the registers that get clobbered and that need saving.
I have done testing and when I modified edi… the routine fails
You should specify all the registers that you use in the input, output and
clobber lists at the end of your asm block to make sure gcc has all that
info.
Alex.