Danny Backx escreveu:
> On Fri, 2007-10-12 at 12:12 +0200, Vitus Jensen wrote:
>>> Since you have eVC access, could you do a stub lib that replaces that
>>> third party lib, that exports the same function, but just prints the
>>> parameters? That way, you can be sure that the lib is seing
>>> the correct parameters, and invalidates/validates the calling
>>> conventions argument.
>> Good idea! As I didn't like the interface anyway I created stub code
>> and placed stub code and lib in a DLL, which I build using eVC. Like
>> this:
>>
>> DWORD __stdcall
>> MyLibConfig(int hd, int subfct, void * parameter)
>> {
>> int res = libconfig(hd, subfct, parameter);
>> if( res == 0 )
>> return liblasterror();
>> else
>> return 0;
>> }
>>
>>
>> It's possible to use this "stub DLL" from mingw32ce, without any
>> "invalid subfunction" problems. This solves my current problem.
>>
>> However it shows that calling conventions are somewhat different when
>> omitting __stdcall. It's not unexpected but it would be nice to use
>> third party libs directly. Especially if someone doesn't have access to
>> eVC.
>
> You may have identified the cause of the problem here. I have been
> looking at the assembler file you provided (from eVC), and the one
> generated by our compiler. I am not too fluent in ARM assembler either,
> so reading this is hard, but the calling conventions do appear
> different.
>
> I then looked in the gcc docs for "stdcall" and found this in
> src/gcc/gcc/doc/extend.texi :
>
> @item stdcall
> @cindex functions that pop the argument stack on the 386
> On the Intel 386, the @code{stdcall} attribute causes the compiler to
> assume that the called function will pop off the stack space used to
> pass arguments, unless it takes a variable number of arguments.
>
Irk. I always thought __stdcall was a no-op in Arm CE, and
in fact it is an alias to __cdecl in mingw32ce/cegcc.
Hummm,
DWORD __stdcall
> MyLibConfig(int hd, int subfct, void * parameter)
> {
> int res = libconfig(hd, subfct, parameter);
>
But, that's strange, because,
then, eVC would see this as stdcall:
DWORD __stdcall
MyLibConfig(int hd, int subfct, void * parameter)
And gcc would see this as:
DWORD __cdecl
MyLibConfig(int hd, int subfct, void * parameter)
So the problem would still be there.
Doesn't the libconfig declaration have any __stdcall/__cdecl or other
calling convention attribute in it? Maybe hidden behing a macro similar
to WINAPI?
> Would your stub be a valid way of converting between two calling
> conventions ?
>
Shure, that's the standard way to work around it. Take a compiler that
supports both calling conventions, and make a wrapper function
exporting the calling convention you want - pretty standard. If you
don't have such compiler handy, you have to resort to an assembly wrapper
instead.
Of course, I'd prefer to fix this. But, first, I'd like to see the declaration
of libconfig *exactly* like eVC is seeing.
Cheers,
Pedro Alves
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
