Is there a way to step into a call without being in the dissassembly view? It looks like it will step into the call if it's in the same source file, but not if it's in a .inc file that is part of the same project.
Posted on 2002-06-22 19:38:56 by grv575
Only if the include has been compiled with debug symbols included.
Posted on 2002-06-23 06:53:45 by sluggy
I have file1.asm which includes file2.inc. After assembling and linking with debug symbols included and start debugging file1.asm, it looks like if the procedure is in file1 it will step into it, but if it's located in file2 it will step over it.
Posted on 2002-06-24 14:14:25 by grv575
That should not be the case. I use VS, and use the method you do (i have 1 "master" asm file which gets compiled, everything else is split into files and included).

The only thing i can think of is perhaps you are getting your "step into" and "step over" keys wrong?
Posted on 2002-06-24 16:38:45 by sluggy
Maybe my compile settings are off?

\masm32\bin\ml /nologo /c /coff /Zi file.asm
\masm32\bin\link /nologo /subsystem:windows /debug file.obj
Posted on 2002-06-24 21:56:43 by grv575
The problem sounds like you are not stepping into the functions, you are just stepping over them, and coincidentally your included file contains the functions, which makes you think it is something wrong with the file.

Your compile/link options look fine. Try setting a breakpoint on where a function is called, cause the program to hit it, then use your F11 key to step into it, instead of your F10 key.
Posted on 2002-06-25 00:08:54 by sluggy
AFAIK, VC has a problem with include files if source file has includes with "real" code in it, at least the older versions. Source level debugging then may not work.

japheth
Posted on 2002-06-25 01:01:34 by japheth
That should not be the case. I use VS, and use the method you do (i have 1 "master" asm file which gets compiled, everything else is split into files and included).


So you put other code files in incs?? If so, where would you include? At the top of the assem file? Or do you include in the code? Please explain more, the idea intrigues me. I am always on the lookout for better ways to setup multi-file projects.

Thanks.
(I use VC7)
Posted on 2002-06-25 01:48:18 by ThoughtCriminal
Just tried this using an asm and one include with code.


LBLCALL TYPEDEF proto

in the asm:

call LBLCALL ptr dxinit

int the inc:

_dxinit:
dxinit label dword
pop esi

invoke LoadLibrary, addr DdrawDll
mov hDDlib, eax

invoke GetProcAddress, hDDlib, addr DDC

push esi
ret

The code above may not work, it was pasted just to test.


Tracing with F11(step-into), with out the typedef, the debugger proceded(sp) just like F10(step-thru). With the typedef, it proceeds as normal and steps into the include file, But...

It returns to the asm file after the first instruction. If you trace using the dissassembly window, it works fine.

I also tested a breakpoint in the included file. The breakpoint did not activate.

Ahhhhhh..... I did all that with my file included at the end of my asm source:


call LBLCALL ptr dxinit

ret
main endp

include \code\inctest\code.inc;****
end start


But if I move the include BEFORE my asm file code, it... works. I have not totally tested it but I can F11 thru just fine. Include like this:


.code

include \code\inctest\code.inc;****

start:
align 4

invoke GetModuleHandle, NULL
mov hInstance,eax


Big difference, depending on where you put it.
Posted on 2002-06-26 12:07:45 by ThoughtCriminal
ThoughtCriminal,
sorry to take so long to answer, i've been busy cloning Oracle databases over the last couple of days (wheee... :) ), and i wanted to give you an example with the answer as well.

Like i said, i use one master asm file, and split everything up into includes, usually something like this:
- library imports
- protos
- global variable declarations
- function exports (.def file)
- any big window message loops
- logical sections of code

Below i have the main asm file of a dll i did recently that does MD4 and MD5 hashing. By setting it up this way, i only have to set compile and link options on one file, not several. Usually in the VC editor, whichever source file has the focus when you press F5 will be the one it tries to compile, but by setting up the one master file you can be editing any source file when you hit F5, and it compiles only the master one.

Like i already mentioned, this is a dll, and it is used by a VB app, but that doesn't matter too much. If i attach a debugger to the VB app's process during execution, i can still debug *everything* in the dll, even if they VB app is running from within the VB IDE (which means the VB debugger is already attached). Believe me, i had to do this several times while i ironed out problems with NULL pointers and VB datatypes etc :grin:

[size=12]

.486
.model flat, stdcall
option casemap : none

DEBUGL EQU 0 ;log debug stuff to file


include imports.inc
include windows.inc
include mdx.inc
include protos.inc

.data
include globals.inc
ptrSum MD5Sum<>



.data?
hHeap DWORD ?



.code
DllEntry proc hInstDLL:DWORD, reason:DWORD, reserved1:DWORD
.IF reason == DLL_PROCESS_ATTACH
DLogStart "c:\md5 dll.log"
DLog " "
DLog "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
DLog "DLL_PROCESS_ATTACH, log file opened"

;create a separate heap for this dll, then if it is running
;inside a debugger or IDE then that app will not intefere
;with our buffers:
;----------------------------------------------------------
invoke HeapCreate, HEAP_NO_SERIALIZE, 2048000, 0
mov hHeap, eax
.IF !eax
;heap generation failed:
;-----------------------
DLog "HEAP GENERATION FAILED, aborting load of dll."
mov eax, FALSE
ret
.ENDIF

.elseif reason==DLL_PROCESS_DETACH
invoke HeapDestroy, hHeap
DLog " "
DLog "DLL_PROCESS_DETACH, end logging"
DLog " "
DLogEnd


.elseif reason==DLL_THREAD_ATTACH
.else ; DLL_THREAD_DETACH
.ENDIF

mov eax, TRUE
ret
DllEntry endp



MDxGetVersion proc
lea eax, Version
ret
MDxGetVersion endp



;MD5 Procedures:
;---------------
include md5.asm


;MD4 Procedures:
;---------------
include md4.asm

end DllEntry
[/size]
Posted on 2002-06-26 18:51:00 by sluggy
Thanks for the example sluggy.


;MD5 Procedures:
;---------------
include md5.asm


;MD4 Procedures:
;---------------
include md4.asm


There is not problems in the dissassembly window with the code veiw for md4 asm? This is what happens when I use 2 incs at the start:


.code
align 16
_dxinit2:
dxinit2 label dword
pop esi
00401030 pop esi
00401031 push offset DdrawDll (403010h)
00401036 call LoadLibraryA (4010A2h)
0040103B mov dword ptr [hDDlib (403024h)],eax
00401040 xor edx,edx
00401042 push offset DDC (40300Ch)
00401047 push dword ptr [hDDlib (403024h)]
0040104D call GetProcAddress (40109Ch)
00401052 push esi
invoke LoadLibrary, addr DdrawDll
mov hDDlib, eax
xor edx, edx
invoke GetProcAddress, hDDlib, addr DDC
push esi
ret
00401053 ret


In my quick test, the first included file works fine, the second cannot figure out where the code lines go properly. I'll try reworking it using your style. Thanks.
Posted on 2002-06-26 20:16:44 by ThoughtCriminal
Hmmm, i see what you mean, it looks a little confused. To be quite honest, i have never noticed this problem with my disassemblies, and i have only had problems with includes if i include them in the wrong order (i.e. put the protos or global vars include after a code include).

Your problem doesn't look like it is something you are doing wrong, i am wondering if maybe you need to apply a service pack for VS?
Posted on 2002-06-26 20:43:24 by sluggy
I'm using VC7(Net). Got all the updates. The VC7 debugger is better than VC6.
Posted on 2002-06-26 21:10:24 by ThoughtCriminal
There should be no problem if you compile the file separetely instead of including it in another asm file. Rename the file to .asm, add it to the project and set the compilation command line in the "Custom Build" panel. You will find more info if you search for "visual studio" or "vc++" in the board . Good luck
Posted on 2002-06-27 00:53:41 by Dr. Manhattan
Dr. Manhattan, thanks for the tip. I am mostly looking at this in my quest for the multi-file project with no EXTERN or PUBLIC, directives. I just plain don't like them. sluggies method works, but with some listing errors. I found my own method by linking using /FORCE, declaring all variables in all files, and EXTERNDEFing the ones that should be global. But I'll always be looking for a better way until I find it.


sluggies metohd would work perfectly if there was a way to combine all the included files into one file that is included with the asm, before assembly, but I think I would be crazy to actually implement something like that.
Posted on 2002-06-27 03:12:15 by ThoughtCriminal
sluggies metohd would work perfectly if there was a way to combine all the included files into one file that is included with the asm, before assembly, but I think I would be crazy to actually implement something like that.
The thing is, it *should* work for you, if the compiler was doing its job properly. One of the first things the compiler should do is to expand out the includes and macros, in the place where they were used (which is why the order you use them can be important). Maybe the VC7 (.Net) debugger is doing this by design. Do you own a copy of VC6? Can you try your source with the VC6 debugger and replicate the problem?
Posted on 2002-06-27 05:41:00 by sluggy
Got 6 here, I'll give it a try.
Posted on 2002-06-27 10:28:30 by ThoughtCriminal
I give up, I can't remember how to enable debug info. I also kept getting a 'corrupt debug info linker' error. VC7 puts all thoese options in places you can actually find them.
Posted on 2002-06-27 11:03:30 by ThoughtCriminal
I explained my problem elsewhere, with a possible solution. The answer I got requires a new step in my build order, but thats okay.

I think i already posted my crazy idea, here it is:

A bat file

copy file1.asm + file2.asm + file3.asm output.asm(inc)

Then include output.asm in my master asm file. I never knew copy could do that...
Posted on 2002-06-27 11:33:20 by ThoughtCriminal