|
Posted by rahul on August 11, 2007, 3:59 pm
Please log in for more thread options
Hi,
I am facing a strange kind of problem. I have a lib which an
application has to use. There is an interfacing layer between the two
which generates a dll. Now when the lib is using all C files, there is
no problem in loading the dll. But when a few C files are replaced by
asm files, the library is not being loaded. The architecture used is
arm9t. I am creating objects of the asm files, and then link to the
lib.
Any help will be appreciated.
Regards,
Rahul
|
|
Posted by wolfe719 on August 16, 2007, 11:32 am
Please log in for more thread options
> Hi,
>
> I am facing a strange kind of problem. I have a lib which an
> application has to use. There is an interfacing layer between the two
> which generates a dll. Now when the lib is using all C files, there is
> no problem in loading the dll. But when a few C files are replaced by
> asm files, the library is not being loaded. The architecture used is
> arm9t. I am creating objects of the asm files, and then link to the
> lib.
>
> Any help will be appreciated.
>
> Regards,
> Rahul
Hello Rahul,
You have given very few details about what might be going on, so it is
very difficult to understand your problem.
You have stated that a DLL is not loading.
Are you loading this DLL dynamically? And the LoadLibrary() function
call is failing?
Are you loading this DLL implicitely (i.e., the DLL is automatically
loaded by the OS when your application is loading)?
In any case - you say that your DLL is not loading. DLLs fail to load
because of a few conditions:
(1) Security Settings Prohibit the DLL from loading - not likely,
unless you are making different system calls in ASM than you are
making in C.
(2) Fixups of functions listed in the DLL's function table are not
successfully completed (function name mismatch, for instance)
(3) The DLL's DllMain() function returns an error code.
You have a DLL created by linking in a library, right? That library
refers to a DLL which has a bunch of functions, all written in C. You
take some number of functions within that DLL and you replace their C
implementation with a ASM implementation, create your DLL, and the DLL
no longer loads properly in your application.
Specifically, I think that you are describing this situation:
APPLICATION (automatically loads) ---> DLL
THEORY 1:
Your DLL is is not loading because an entry point specified in the LIB
file does not actually exist in your new ASM-implementation DLL.
OR, your EXE is not loading because your DLL automatically loads the
DLL, and with the new DLL, your application no longer loads.
This could be caused because your DLL expects a name-mangled function
entry point and your LIB says it provides that function - but the
corresponding DLL actually does not provide that function's entry
point.
This is often caused because you are building your application with a
stale version of LIB file. One of the most common reasons for this is
a LIB file that is copied by hand from the DLL's project into the
application's project.
For this issue, check the LIB's function names using the Visual Studio
tool lib.exe
Also check the DLL's function names using the Visual Studio tool
dumpbin.exe
I think you will find that the ASM functions do not have the same
function names -- and you will have to sort that issue out -- perhaps
by using an extern "C" construct around your function calls (both
in the function's header file AND within your DLL's C files.
THEORY 2:
Your DLL is not loading because it depends upon a different DLL's non-
existant function. So when the OS's loader goes to fix up the bad
function pointer in the DLL's function table, the loader fails to find
the specified function -- causing the whole DLL to be rejected.
This, unfortunately, is VERY easy to do in ASM, as a simple mispelling
could compile just fine, but die when you try running things.
THEORY 3:
Your DLL is not loading because the DllMain() function calls a
function written in ASM, and that ASM function fails for whatever
reason. That failure could be a bad return code, or it could be a
crash - which the OS captures and reports as a failed DLL loading.
This theory is easy to check - as you can either breakpoint on the
DLL's DllMain() function - or you can throw out a OutputDebugString()
call, and see if that call ever shows up in your Debugger's Output
Window. You might want to put a few OutputDebugString() function
calls in key places in your code, just to see if they are ever hit
when your DLL does not load.
Good luck - and let the group know what your problem ended up being.
John Wolfe
Lobo Consulting
wolfe719@lobo.us
|
| Similar Threads | Posted | | Re: Loading local files with Microsoft.XMLDOM | May 22, 2007, 12:13 pm |
| Problem in playing back video files with DirectShow on Windows Mobile 6.0 | September 1, 2008, 10:20 am |
| 3gp files | March 2, 2007, 11:58 am |
| Branding files | April 20, 2006, 3:50 am |
| Help with signing CAB files | March 22, 2007, 11:59 am |
| Packaging JAR files in CAB? | April 24, 2007, 8:51 pm |
| Packaging JAR files in CAB? | April 24, 2007, 8:52 pm |
| Packaging JAR files in CAB? | April 25, 2007, 2:16 pm |
| ID SHGetSpecialFolderPath in cab files? | May 6, 2008, 7:15 am |
| put some files in Emulator's folders | June 23, 2005, 12:07 am |
|
XML Sitemap