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.

Would your stub be a valid way of converting between two calling
conventions ?

        Danny

-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Attachment: signature.asc
Description: This is a digitally signed message part

-------------------------------------------------------------------------
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

Reply via email to