Debugging techniques - tracing

[cprog123]

This is a spinoff of http://forum.pellesc.de/index.php?topic=4531.0, but I wanted to make sure I don't clutter the other thread on a new question. When trying to solve a linking problem, timovjl said the following.

__C_specific_handler seems to be missing from pocrt64.lib.
In crtmt64.lib it is in _ehandler.obj.
Maybe this is a bug.

To better understand debugging steps, I have some questions. There are different types of tools available that I have been aware of, that allows a programmer to trace program execution. Debuggers, tracers, process spy and etc. I never tried any of this, so I thought this might be a good time to do so. How can you trace the handler down to _ehandler.obj. What tools can you use to find this out.

[TimoVJL]

How can you trace the handler down to _ehandler.obj. What tools can you use to find this out.

I use podump.exe (and PEView.exe) to examine libraries.

[cprog123]

Could you walk through the steps that led you to the conclusion about the handler? also where can I find peview?

[TimoVJL]

also where can I find peview?

PEView.exe
http://www.magma.ca/~wjr
http://www.magma.ca/~wjr/PEview.zip

Could you walk through the steps that led you to the conclusion about the handler?

Open pocrt64.lib with PEView and look at IMAGE_ARCHIVE_LINKER_MEMBER Offset Table to find missing function.
Do same with crtmt64.lib and and follow Offset to header. It points to _ehandler.obj.

[Vortex]

Hi cprog123,

You could use polib to extract _ehandler.obj :

Code: [Select]

polib.exe /explode crtmt64.lib
Polib will output all the object modules.

[cprog123]

I followed the instruction to use PEview, but I am not sure I understand by what you mean when you say follow Offset to header. I can only highlight the row. There seems to be an address and or offset, that's all. I'm not sure how to find _ehandler.obj or why and what to look for. So for example what am I supposed to understand from what is pointed to by what and how do I find this.

Still getting my bearings on this. PEview looks like a nice and useful utility. My assembler is somewhat weak, sorry.

[TimoVJL]

If Offset to Header Data is 0001CC8A find IMAGE_ARCHIVE_MEMBER_HEADER 0001CC8A
then you see string c:\pc_32_700\pocc\crt\src\objmt64\_ehandler.obj

You can extract it with

Code: [Select]

polib.exe /EXTRACT:_ehandler.obj crtmt64.liband try to additionally link it in your prog_1.ppj project for testing purbose.

[CommonTater]

I followed the instruction to use PEview, but I am not sure I understand by what you mean when you say follow Offset to header. I can only highlight the row. There seems to be an address and or offset, that's all. I'm not sure how to find _ehandler.obj or why and what to look for. So for example what am I supposed to understand from what is pointed to by what and how do I find this.

Still getting my bearings on this. PEview looks like a nice and useful utility. My assembler is somewhat weak, sorry.

Not wanting to discourage you by even the most tiny bit, but....
I find myself wondering what your level of skill is and if this is really helping you...

For a beginner to get off on a tangent like this can be extremely confusing since in all my time programming I've only done this once.  It is definately not routine programming activity. So, if you are still weeding through syntax lessons and general concepts, I'd suggest you simply select the multithreaded lib and report this as a bug so you can get back to your lessons. 
 
As interesting as this whole tearing things apart exercise is, it is very unlikely you are actually going to fix it.

(Edit: I definately need my second cup of coffee this morning!)

[cprog123]

Oh, right. I forgot to mention, that as I am working on my C experience, I am sometimes branching off and learning new techniques. Most of the time, I go through simple examples that don't really mean anything I could make use of, but it exposes me more to debugging techniques and so on. So I think your right, I won't probably fix this problem, but it does help somewhat. I do follow directions.

[CommonTater]

LOL... Was a time I said someting similar... IIRC: "I'll never use a linked list"... and guess what I'm doing now... Yep using linked lists to queue up network activity...  Never say never...

The reason I mentioned it is that I've found when learning something new, I am best to develop a sort of tunnel vision... focusing on the courseware exclusively.  I will make a note to come back to something.  But for the most part I find distractions to be very counterproductive. 

Now... that's MY experience, yours may be a little different... but at the same time I didn't want to see you get all tripped up on something unrelated to your courses.

[cprog123]

That is exactly, why I'm happy you brought it to my attention. Everyone needs a little reminder every once in a while. So I won't spend too much time on tracing the lib, but it was interesting enough.

I think I'm getting ready to start a "How do I ... in inline asm" thread. I never worked with C and inline asm. The lib tracing got me interested in maybe pushing for a little extra power.

[CommonTater]

I think I'm getting ready to start a "How do I ... in inline asm" thread. I never worked with C and inline asm. The lib tracing got me interested in maybe pushing for a little extra power.

Yep, there are times when you have to dip into ASM a little.  Look at my Garbage Collector Experiment in the user contributions forum for one example... 

But, beware the "premature optimization" demon... ASM is not necessarily faster than C and in some cases it can be slower and/or bigger...  A good example of this is trying to second guess the runtime library which in most cases is exhaustively tested and optimized before you ever see it.  Most C compilers produce very tight code these days and are quite smart about it.  Usually I will only use ASM as a last resort, when there is no way to duplicate the behaviour in C... 

That said ASM is an interesting challenge and definately worth learning to at least a beginner level. I don't use it much but then most of what I code is pretty straightforward WinApi stuff... I believe Vortex is your guy for ASM.