Archive: debian package advice re System.dll
debian package advice re System.dll
I've found that if I strip out the code related to System::Call from System.dll, then I can build the dll fine. This results in a fairly crippled System.dll that can't be used in the examples that rely on System.dll, because most of these use System::Call as well as the other functions.
Do people think that the System.dll functions Alloc, Free, Copy, Store and Int64Op are worth shipping a crippled System.dll in debian?
System::Call is the heart of the plug-in. I think a better idea would be to use some program that converts the ASM code. GCC just wants a different syntax...
Do you know of any such program? Or some document comparing the two syntaxes?
I don't know such a program. The two syntaxes are Intel's and AT&T's, as far as I remember. There's also a different in block identifier and type (__asm {mov eax, 1} vs. asm("mov %eax, 1")). I don't remember which names goes to which syntax.
Suppose I manage to translate the assembly to AT&T syntax, how will this be managed? Will the Intel version change often enough for the AT&T version to become out of sync?
OK, converted most of the assembly to gcc syntax. I'm getting 3 errors:
build/release/System/Source/System.o:System.c:(.text+0x116f): undefined reference to `proc'The first is because I don't know how to refer to function parameters in gcc asm.
build/release/System/Source/System.o:System.c:(.text+0xf43): undefined reference to `alloca_probe'
build/release/System/Source/System.o:System.c:(.text+0x10b2): undefined reference to `__LOCAL_SIZE'
It seems impossible to strip it all out. How do you push a variable number of parameters to a function when the number is set at runtime? How do you create a __stdcall function that accepts a variable number of arguments?
The Intel version will probably not change much, but it'd be better to have a script that automatically converts prior to compiling.
I wrote a script that gets most of the way to an AT&T version, but the remaining 10% (needed for proper comilation) would require implmenting a proper assembly tokeniser. I think it would be much easier to just stick ifdefs around the place and add the AT&T version too.
Would this be acceptable? If so, I hope to get it done in time for inclusion in 2.11.
Were you able to get around __LOCAL_SIZE and alloca?
An ifdef is acceptable. Of course, a conversion script is always preferable.
Nope, not yet able to port __LOCAL_SIZE and alloca. I'll keep digging though.
Cool, I'll get working on the ifdefs.
In wine, alloca_probe just subtracts the value in eax from esp:
http://cvs.winehq.org/cvsweb/wine/dl...-cvsweb-markup
Also found a mention of gcc/__LOCAL_SIZE together:
http://66.102.7.104/search?q=cache:G...__GNUC__&hl=en
I don't know how WINE handles alloca, but it's more than just subtracting a value from ESP. All references to local variables should be offseted once the value of ESP changes.
OK.
Another problem - gcc does not support the naked attribute on pe-i386. You can read a flamewar about that here:
http://gcc.gnu.org/ml/gcc/2004-02/msg00939.html
http://gcc.gnu.org/ml/gcc/2004-02/threads.html#00939
More links:
http://www.winehq.org/hypermail/wine...4/03/0408.html
http://gcc.gnu.org/onlinedocs/gcc/Fu...n%20Attributes
http://www.cs.cornell.edu/courses/cs...nventions.html
Hmm, perhaps the cdecl function attribute is the appropriate one to use?
cdecl is not quite the same thing as naked. It does less than stdcall because it doesn't clean up the stack, but it still initializes the stack in the epilog and uninitializes it in the prolog. It also probably pushes registers and makes room for the local variables. At least you won't need __LOCAL_SIZE...
OK, I'll try that and see if it works.
BTW, this might take a while, so feel free to release in the meantime.
Couple of things I found, that might be helpful:
http://wiki.bfh.ch/index.php/Inline_...r_with_the_GCC
http://www.niksula.cs.hut.fi/~mtiihone/intel2gas/
Not sure if I'll be able to finish this any time soon. I've attached the current unfinished patch for anyone who wants to work on this.
A Debian user is working on converting the code to pure GCC assembly so that System::Call can be compiled on Linux and other non-Windows operating systems.
http://bugs.debian.org/cgi-bin/bugre...?bug=319999#40
full System::Call support on Linux, testing needed
Hi all, I've received a patch for full System::Call support on Linux. It changes how System.dll is compiled on Windows and therefore needs testing on Windows too. Please test gcc-system-call-2.patch from here:
http://sf.net/support/tracker.php?aid=2193442
Those of you who build NSIS on Windows using the scons build scripts, I'd be grateful if you could test it. Please also test any installers you can create with it too. The example nsi files from NSIS work fine with it, but it might break some other installer and I don't want any regressions.
BUMP!
Someone, anyone, please test the latest version of the patch (gcc-system-call-3.patch).
Builds fine and the example seems to work fine.
Cool, thanks for testing.
Did you want to review the patch before I commit it?
I want to give it a very good look before it's committed.
Committed and will be included in the next version - 2.42.