|
|
Okay
The function is init_image at the bottom
I call it from my main() exe
This all started when I wanted to see what thread('s) came in on the THREAD_ATTACH so decided to play around with StacKwalk in imagehlp.dll etc.....
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
i = 4;
break;
case DLL_PROCESS_DETACH:
i = 3;
break;
case DLL_THREAD_ATTACH:
threadhndl = 0;
DuplicateHandle( GetCurrentProcess(), // Source Process Handle.
GetCurrentThread(), // Source Handle to dup.
GetCurrentProcess(), // Target Process Handle.
&threadhndl, // Target Handle pointer.
0, // Options flag.
TRUE, // Inheritable flag
DUPLICATE_SAME_ACCESS );// Options
processhndl = 0;
DuplicateHandle( GetCurrentProcess(), // Source Process Handle.
GetCurrentProcess(), // Source Handle to dup.
GetCurrentProcess(), // Target Process Handle.
&processhndl, // Target Handle pointer.
0, // Options flag.
TRUE, // Inheritable flag
DUPLICATE_SAME_ACCESS );// Options
memset( &c, '\0', sizeof c );
c.ContextFlags = CONTEXT_FULL;
GetThreadContext(threadhndl, &c);
s.AddrPC.Offset = c.Eip;
s.AddrPC.Mode = AddrModeFlat;
s.AddrFrame.Offset = c.Ebp;
s.AddrFrame.Mode = AddrModeFlat;
while(1)
pSW(imageType, processhndl, threadhndl, &s, &c, NULL, NULL, NULL, NULL );
// while(1)
// StackWalk(IMAGE_FILE_MACHINE_I386,
// processhndl,
// threadhndl,
// &s,
// &c,NULL,NULL,NULL,NULL);
break;
case DLL_THREAD_DETACH:
i = 2;
break;
return false;
}
return TRUE;
}
__declspec(dllexport) void init_image(void)
{
imageType = IMAGE_FILE_MACHINE_I386;
pSW = NULL;
hImagehlpDll = NULL;
hImagehlpDll = LoadLibrary((LPCWSTR) "imagehlp.dll" );
pSW = (tSW) GetProcAddress( hImagehlpDll, "StackWalk" );
return;
}
Thankx
|
|
|
|
|
Is that an infinite while loop inside your DLL_THREAD_ATTACH case?
|
|
|
|
|
Yes; just wanted to Walk thru the stack
When I load imagehlp.dll in my main exe it works (the LoadLibray) however not in the export'ed function (that lives in
the DLL source)
in order to get all the variables LoadLibrary (handle) and ProcAddress to the DLL I would have to export it thought it
would be simpler to have all the code in the same source as the DLL where In THREAD_ATTACH I would see what thread
attach'ed to the DLL via StackWalk and other imagehlp functions
Thankx again
|
|
|
|
|
Does this fix it?
hImagehlpDll = LoadLibrary((LPCWSTR)L"imagehlp.dll" );
Note the 'L' notation for wide string.
|
|
|
|
|
|
ForNow wrote: hImagehlpDll = NULL;
Is hImagehlpDll a pointer?
ForNow wrote: hImagehlpDll = LoadLibrary((LPCWSTR) "imagehlp.dll" );
Does hImagehlpDll have a non-NULL value? Why the cast? Use L or _T() instead for your string literals.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
ForNow wrote: I seem to be having problems ???
Are we supposed to guess what these problems are?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Sorry dont know Where that thread came from
I did a LoadLibrary in my main executable for imagehlp and it worked... however what I was hoping to see is in my DLL when I get the thread_attach message is to identify the thread
Some one suggested the use of StackWalk so.....
Orignally I did the LoadLibrary in DLLmain but I was quickly told that was a big no no ... As the OS namely Windows hold locks while processing DLLmain as it is shared code among .exe and DLL and I would cause a deadlock
So.. I put the code for this (the LoadLibrary and GetProc in a exported function in the same source as my DLL
My main .exe imported this function and I called the function in a another DLL that was "implicity loaded" (hope that is right term as opposed to Dynamic Loaded e.g. LoadLibrary) in my main .exe a few lines after my startup code from my main .exe
I think calling a exported function from a DLL which does a LoadLibrary maybe the problem
Dont Know
Thankx again
|
|
|
|
|
Sorry the Value returned from LoadLibrary was NULL
|
|
|
|
|
So why are you then not calling GetLastError() to find out why?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I got a x7e ERROR_MOD_NOT_FOUND
But thats not it
When I do the load in the main its okay When I call the exported function init_image it fails
int main(int ac,char *av[])
{
int rc = 0;
HINSTANCE hImagehlpDll;
hImagehlpDll = LoadLibrary((LPCWSTR) "imagehlp.dll" ); <--- Okay
init_image();
code in DLL source
__decspec(dllexport) void init_image(void)
{
DWORD myerror;
DWORD DWfLAGS = FORMAT_MESSAGE_FROM_SYSTEM || FORMAT_MESSAGE_ALLOCATE_BUFFER;
DWORD size = 100;
char mybuffer[100];
LPTSTR error_ptr;
imageType = IMAGE_FILE_MACHINE_I386;
pSW = NULL;
hImagehlpDll = NULL;
hImagehlpDll = LoadLibrary((LPCWSTR) "imagehlp.dll" ); <--- fails here
myerror = GetLastError();
// FormatMessage(dwFlags,NULL,myerror,NULL,error_ptr,size,NULL);
pSW = (tSW) GetProcAddress( hImagehlpDll, "StackWalk" );
return;
}
|
|
|
|
|
What does wide L mean ????
|
|
|
|
|
ForNow wrote: What does wide L mean ????
The L is not wide, but the string it precedes is.
Use the L prefix to denote a wide-character character literal or a wide-character string literal.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Thankx Can I buy you lunch one day
Honestly one of the things I noticed with this problem coming from a MainFrame
Background is (using MainFrame Sercvices) When you want to use one of the Authorized
Assembler services IBM always prefaces the discription of the macro by requirements
Such as must be Authorized state or No Locks Held
There is no such documentation on Windows API's
|
|
|
|
|
ForNow wrote: There is no such documentation on Windows API's
Are you referring to MSDN?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I was refering in MSDN if they are are any requirements when using an API
shuch as no Locks held etc....
I guess I found out they are certin things I cann't do in DLLMain
Thankx again
|
|
|
|
|
A few questions regarding use of the inline key word
1) Do you use it?
2) How do you decide when to use it?
3) Do you ever actually measure the benifit of using it?
4) Can using it ever degrade performance?
5) Can the effect of using it vary on different hardware or operating systems?
|
|
|
|
|
Josh Gray wrote: 1) Do you use it?
Yeah.
Josh Gray wrote: 2) How do you decide when to use it?
When the overhead of a function call is comparable to the overhead of the function itself. For example, a simple accessor function.
Josh Gray wrote:
3) Do you ever actually measure the benifit of using it?
Very rarely.
Josh Gray wrote: 4) Can using it ever degrade performance?
I guess it's possible. If you inlined a frequently called large function you would increase the size of the EXE. Remember that the compiler has the last say however: it doesn't have to inline a function you've marked as inline if it decides it's not worth it.
Steve
|
|
|
|
|
Thanks mate
Stephen Hewitt wrote: I guess it's possible. If you inlined a frequently called large function you would increase the size of the EXE. Remember that the compiler has the last say however: it doesn't have to inline a function you've marked as inline if it decides it's not worth it.
What I've been wondering about is the effect this has on hardware optimisations. For example instruction pipe lines and cpu caching.
I'm going to do some experimenting to see if making some functions inline has any real world effect
|
|
|
|
|
Josh Gray wrote: I'm going to do some experimenting to see if making some functions inline has any real world effect
You will not see much difference if you do not disable optimizations. The MSVC compiler is very intelligent with its inlining and will very often inline your functions even if you did not ask it to.
Best Wishes,
-David Delaune
|
|
|
|
|
Josh Gray wrote: 1) Do you use it?
Actually recent Microsoft compilers are fairly good at determining which functions to inline. I still use it to make sure the compiler gets the hint. It should be noted that the __inline keyword is simply a compiler hint and may be completely ignored if the compiler determines its not the best choice. In cases where you want to overide the compilers decision you can use __forceinline. But once again this is simply a hint the compiler may ignore. Although it could be described as a 'strong hint' to the compiler.
Heres a good tip. The only 100% sure method to have your function inlined is to use the #define keyword.
Josh Gray wrote: 2) How do you decide when to use it?
Function calls have overhead, they are not free. The stack and registers of the calling function must be saved and restored. All of ther function arguments are copied into registers... then a stack frame needs to be set up for the local variables in the new function.
I mostly use it for returning member variables such as:
__inline int MyClass::GetVar() const { return myVar; }
If there is work that needs to be done many times in a loop it is sometimes better to inline the function. The compiler may choose to automatically inline the function if it meets whatever criteria. Otherwise you may be force to use __forceinline before the compiler actually takes your advice. It doesn't trust you, and maybe you shouldn't either!
for(int i = 0; i < iSomeLimit;++i)
{
DoWork(SomeArray[i]);
}
Josh Gray wrote: 3) Do you ever actually measure the benifit of using it?
Yes, you can read the RDTSC[^] counter to get a rough idea of the function performance before and after inlining.
Josh Gray wrote: 4) Can using it ever degrade performance?
Yes, most definately!
It is important NOT to inline functions that are very large in size. The reason is that the processor instruction pipeline[^]is always reading ahead and storing future instructions in the pipe so that it can execute it very fast, but it may make a mistake and cache the wrong instructions! While the processor is excuting instructions... it is at the same time trying to predict where the code will JMP to next. This is called branch prediction[^]. So if your function is extremely large it can degrade program performance by increasing page faults and cache misses.
Josh Gray wrote: 5) Can the effect of using it vary on different hardware or operating systems?
Yes.
Optimizations work differently on many flavors of Intel and AMD microprocessors because the instruction pipelines have different sizes/implementation, the branch target buffer[^] may be a different size and they may contain different sizes of L1, L2 and L3 cache.
Inline at your own risk!
Hope this helps,
-David Delaune
|
|
|
|
|
Randor wrote: Heres a good tip. The only 100% sure method to have your function inlined is to use the #define keyword.
I only ever use macros, for whatever reason, if I have no other choice; and even then with some sadness.
Steve
|
|
|
|
|
The only other things I can add on top of the other replies are:
- if a function is virtual the inline keyword is ignored (clearly it has to have an address)
- I think inline is ignored in debug builds
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
Hi!
I'm developing IE toolbar and I need to know when user opens new site. I suppose that i need to add command message handler (ON_UPDATE_COMMAND_UI), but I dont know right message ID. could someone post me the right ID or correct me if i'm wrong.
Greetings
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
