tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tinycc-devel] stdcall support


From: Thomas Harning Jr.
Subject: [Tinycc-devel] stdcall support
Date: Tue, 07 Oct 2003 19:01:18 -0400

I've been tryin' to test out my WIN32 version of TCC and it works quite good so far. I got it to work on MinGW first, and after a wee bit of tweaking and removing the bounds checker, and making it static, I was able to make it compile and work in Visual Studio .Net 2003 [which has very high ANSI compliance].

I've been playin around with it and seeing if I could use a sound library [just a small test kind of thing, to see if its do-able] and have found that stdcall functions don't work very well.

The way i loaded the library was load the LoadLibrary, GetProcAddress, ... into the TCC symbols from the non-TCC program... those worked fine. But I ran into the big problem that the calls crash out because they're stdcall. The functions are declared as __stdcall [which I adjusted to __attribute__((stdcall)) . The library provided a setup so that all the functions could be declared as pointers to the functions with the stdcall attribute, which is how I loaded the library's functions... however that failed. Another try at doing this was loading the library implicitly [via the .lib file] into the non-TCC program and adding the symbols to the TCC program, and that failed the same way. One thing that I've done to get one of the Windows functions to work on TCC [the Sleep function... was in my first TCC test] was to wrap the function in a non-stdcall function... [also the same for LoadLibrary GetProcAddress, etc...] but that to me is a pain, especially when a library has tons of functions to use.

I tried looking through the TinyC compiler's code but couldnt really pinpoint where cdecl and stdcall functions are setup... I saw a parsing part that set the attribute to the thing, but nothing about the code generation for that.

Hopefully there's a quick-fix for this or its next on the development list, because it'd be nice to call the library functions from a 'script' if called for [though for my programs I expect to have things wrapped up... but thats besides the point].

Thomas Harning Jr.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]