The MASM Forum Archive 2004 to 2012

I've been using VS6 as my debugger for the last several years. Unfortunately it doesn't work under Windows 7 and I don't want to run a virtual machine all the time. VS2008 seems a little quirky (trace doesn't accurately display the command just executed) and not as responsive. Ollydbg doesn't seem to use symbol files, or am I missing something?

I can use Windbg just fine except it doesn't know about all of my labels. It knows all of the data symbols and the public labels for jumps. I need to be able to disassemble code and set breakpoints anywhere in the program, not just at the public functions. With VS6 I could do that. With Windbg I need to assemble an "int 3" wherever I want to start debugging. I'm working with a dll and have the build process creating a pdb file.

Looking at Olly 1.10 (instead of beta 2) I see it does import symbols. However, it has the same limitation of not knowing about all of my private labels used for jmp's and call's. Does anyone know how to change source, assembly, or linking to make these available? VS6 had them all.

To put break point in your code,use debugbreak instead of int 3.
Debug of a dll with windbg need a break point.
i use Windbg to debug dll with the source code like that.
This need the full options to made the .pdb
          ml : Zi Zd
         link   /DEBUG /debugtype:cv
Then winddbg need to know where are the .pdb and you have to set it's environment variables like _NT_SYMBOL_PATH and so on.
Windows symbols must be also be up to date.

Quote
-c ".sympath+ SRV*C:\WINDOWS\Symbols*http://msdl.microsoft.com/download/symbols"

When it's done , he can claim that he want others symbols,but if it follow the source code of the dll you haven't anything else to do.

If you use PROCs, just make them public. If you use labels, use a double :

MyProc proc public p1:dword
...
public_label::
...

Link it with the /debug switch as ToutEnMasm said and they should show up in windbg.
You might also need another link switch "/debugtype:cv"

Quote from: sinsi on June 26, 2009, 06:55:37 AM
If you use PROCs, just make them public. If you use labels, use a double :

Code Select Expand


MyProc proc public p1:dword
...
public_label::
...

Link it with the /debug switch as ToutEnMasm said and they should show up in windbg.
You might also need another link switch "/debugtype:cv"

It's messy. I can't convince Olly1 to display local labels, but the procs (TestLoc) and global variable names (r4pos) work:
(http://www.webalice.it/jj2006/pics/OllyOneWithLabels.png)

Proc names are displayed without the public keyword, global labels with a single colon. ML version 9.0 chokes, but JWasm version 6.14 work fine. Olly2 does not display any symbols, unfortunately... :(

jj, I only use windbg so I can't help with olly (tried it once or twice, but I'm a dos debug-ger at heart).
I also try to use ida pro, but it's complex...

Thanks for all the suggestions. I can get the labels to show up by using the 'Public' statement. Double colons didn't seem to make a difference. I have the /debug:full and /debugtype:cv on the linker and /Zi and /Zd on ml. I was hoping there was a way to make local labels show up, as I have about a thousand of them (or more). In VS6 debugger I could use Ctrl+G to go to a local label.

Another issue, I'm merging several souce files with include's, as I am assembling a Dos and a Windows version of my program and much of the code is common to the two versions. The include's  seem to break all source code corollation with any debuggers I've tried. They only know about the top level source file, which is OS-specific, and don't know about the included files which is where most of the code is.

Quote from: andrewz on June 26, 2009, 01:14:45 PM
I was hoping there was a way to make local labels show up, as I have about a thousand of them (or more).

This works:
Externdef   MyLocalLabel:NEAR

Settings:
ML version 6.14 /Zi /Zd
Link version 5.12.8078 /debug
Olly version 1 of 23 05 2004

Note that many other combinations do not work. For example, ml version 9.0 or JWasm do not work correctly.
Below a snippet for testing.

include \masm32\include\masm32rt.inc

MyProc PROTO: DWORD, :DWORD

Externdef MyLabel:NEAR
Externdef MyLocalLabel:NEAR

.data
MyDword dd 123
MyFloat REAL8 123.456
MyString db "Ciao", 0
hw db "Hello World at 1024 bytes", 0

.data?
AnyVar dd ?

.code
start: jmp MyLabel
m2m AnyVar, MyDword
MyLabel:
int 3 ; for Olly
mov eax, 12345678h
mov AnyVar, eax
invoke MyProc, offset MyString, MyDword
print offset hw, 13, 10, 10
getkey
exit

MyProc proc ptrMyString, MyDwordArg
LOCAL LocBuffer[260]:BYTE
  lea edx, LocBuffer
  jmp MyLocalLabel
  xor eax, eax
MyLocalLabel::
  ret
MyProc endp

end start


Picture attached.

[attachment deleted by admin]

i think the double colons make the label public, as in usable from other procs


proc1 proc

     jmp label1

proc1 endp

proc2 proc

label1::

proc2 endp

Quote from: dedndave on June 27, 2009, 12:02:57 AM
i think the double colons make the label public, as in usable from other procs


proc1 proc

     jmp label1

proc1 endp

proc2 proc

label1::

proc2 endp

Yes and no: Yes in combination with Externdef, no because it is visible in Olly with a single colon and no externdef.

EDIT: Wrong, plain wrong...! Olly plays tricks: It keeps info from previous versions, which made me believe that it works with one colon. It doesn't. You have to delete the *.udd file to see the real behaviour :green

so - am i good or am i bad ?
i am close, i know that much because i had to use it last week - lol

Quote from: dedndave on June 27, 2009, 12:48:10 AM
so - am i good or am i bad ?

You are brilliant :bg

Olly is a fine tool, but occasionally it plays foul. Too bad that version 2 does not know about symbols... :(

QuoteYou are brilliant  :bg

dunno if i would go that far