PB9 Debugging a dll?

[Todd Wasson]

I searched and didn't find a thread on this, so here goes:

Is it possible with PB9 to use the debugger to track through a dll written in PB9? How about if the PB9 dll is called by an exe written in another language?

EDIT: One more question. I'm having difficulties compiling one of my programs with PB9 at the moment because any time the variable name "point" is used anywhere I get a duplicate name definition error. This did not happen in PB8. I read that there is some different compiler scanning technique at play here (back/forward referencing for variables or something of that nature). Could this be causing it, or does the compiler just not like the word "point?"

Thanks

[José Roca]

Could this be causing it, or does the compiler just not like the word "point?"

Au contraire. It likes it so much that it is a built-in structure.

[Todd Wasson]

Au contraire. It likes it so much that it is a built-in structure.

Argh... Ok. I figured that was the case. So much for using the word point from now on then. Thanks.

[Eddy Van Esch]

Todd,

To debug a dll with the PB debugger, I include it as source code to a test program.
I use a flag as an option during compile time so that I can easily select to have the test program call the dll functions from the dll or as internal functions.

The test program contains this code snippet:

#COMPILE EXE
#DIM ALL

'%DLL_EMBEDDED = 1  'Include this line or comment it out
                    'If commented out: calls dll functions, if included includes dll source code

#IF %DEF(%DLL_EMBEDDED)
    #INCLUDE "dll.bas"         'Include dll source code
#ELSE
    #INCLUDE "dll.inc"         'Include dll header file
#ENDIF

The dll contains this code snippet:

#IF NOT %DEF(%DLL_EMBEDDED)
    #COMPILE DLL "DLL.dll"
    #DIM ALL
#ENDIF
...
#IF NOT %DEF(%DLL_EMBEDDED)
    FUNCTION LIBMAIN(...) AS LONG

    ....
    END FUNCTION
#ENDIF

Kind regards

[Michael Mattias]

Duplicate declaration can be caused by a structure definition in an INCLUDE file.

"sid" was the one which got me. (there is a TYPE SID in WIn32API.INC).

I put in an NSF a long time ago that the "duplicate definition" error be enhanced to show "symbol <offending word> previously defined in file <filename> [line <lineno>]", but that has not (yet?) occurred.

Regardless there actually is a useful tip in the error reference of the help file: move the offending line of code to the the FIRST line of your program, before anything else, and compile. Now you will get the duplicated definition error on the SECOND occurence of the symbol... which is actually the FIRST occurrence when you put your code back where it belongs.

Simple enough to do...

#COMPILE EXE 

FUNCTION Foobar (<offending varname> AS <real type>) AS LONG
 FUNCTION = 0
END FUNCTION

... REST OF PROGRAM HERE...
...

MCM

[Michael Mattias]

#COMPILE    EXE  
OR 
#COMPILE  DLL 

#IF %DEF(%pb_exe) 
  FUNCTION PBMAIN() AS LONG 
      Prompt for input params and make calls to FooBar 
      ..........
  
  END FUNCTION
#ELSE
 FUNCTION LibMain (.....

 END FUNCTION
#ENDIF 

#IF %DEF(%pb_exe) 
  FUNCTION FooBar (params) PRIVATE AS whatever 
#ELSE
   FUNCTION FooBar ALIAS "Foobar"  (params) EXPORT AS whatever 
#ENDIF
   Code of interest
END FUNCTION   ' end foobar

But to answer your question: No, the PB stepping debugger cannot not be used to debug functions in your DLL when called from another module.

However, TRACE and the other #TOOLS work in DLL modules.

[Todd Wasson]

Ok, thanks for the help. I figured this was the case, but the C++ programmers on our project gave me a hard time about it, insisting it must be possible. I thought it was a nonsensical notion and they were speaking dribble

My duplicate name definition problem was because I use "point" as a variable or array in numerous places in my code. A minute or two using find and replace cleared it up, although it would be nice if I could still use "point" as a name. Ah well.. I can learn to live with that.

That being said, I've had PB9 for two days now. The latest PowerBasic Gazette describing the typical debugging problems seemed directed perfectly at me. The $99 upgrade even just for the #DEBUG DISPLAY ON directive is well worth it. I found three out of bounds errors that I likely never would have otherwise caught. Kudos to Bob Zale and the PowerBasic team on this one! Great work, guys. Keep it up! :applaus:

[Michael Mattias]

but the C++ programmers on our project gave me a hard time about it...

Just tell 'em Real Men Don't Need No Stinkin' Stepping Debugger.

[Cliff Nichols]

On the side of using an executable (DLL or EXE) and debug a problem..."Yep I wish there was a way to step through what I did not write" but we all know that is a wish list (and opens doors to SUCH a contreversy that I will not bring up)"

if you have access to the code though then include it and debug....."Life-Saver" when trying to track down concepts of "I did NOTTTT think of this"....


and to coin a spar....'REALLLLll Men accept when they may be wrong, research why they may be wrong and fix what may be wrong so that they can not be busted later"

AKA...if you can not find it...use all the tools available to you to show you the problem, when you can see the symptoms of the problem.

and I do NOT care what programming language you use.....If you get toooo smug in your stance...someone is BOUND to show you a situation where you are wrong

[Barry Marks]

Ok, thanks for the help. I figured this was the case, but the C++ programmers on our project gave me a hard time about it, insisting it must be possible. I thought it was a nonsensical notion and they were speaking dribble

The PB debugger won't do it. They're using tools that will. It's the sort of thing C programmers do all the time.

Actually their tools will probably debug your DLL just fine but they'll show it as assembly or machine code, not Basic. It won't know how to display it as Basic code. It's very do-able if you know assembly but probably even if you did it would be easier to do it the way they've shown you in the other posts.

Barry

[Todd Wasson]

They do it in MSVC++, but that's because they're starting in their own exe code and then tracing it into their own C++ dll code, all compiled together. I didn't really expect there was a way to do it, but figured I'd ask anyway. Never know...