Announcement

Collapse
No announcement yet.

PB9 Debugging a dll?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • PB9 Debugging a dll?

    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
    Last edited by Todd Wasson; 31 Mar 2009, 07:58 PM.
    Todd Wasson
    http://PerformanceSimulations.Com
    PowerBasic Racing Simulator (October 2007 clip - 15.1MB wmv file) http:http://www.performancesimulations.co...m-GenIV-12.wmv

  • #2
    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.
    Forum: http://www.jose.it-berater.org/smfforum/index.php

    Comment


    • #3
      Originally posted by José Roca View Post
      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.
      Todd Wasson
      http://PerformanceSimulations.Com
      PowerBasic Racing Simulator (October 2007 clip - 15.1MB wmv file) http:http://www.performancesimulations.co...m-GenIV-12.wmv

      Comment


      • #4
        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:
        Code:
        #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:
        Code:
        #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
        Last edited by Eddy Van Esch; 1 Apr 2009, 06:56 AM.
        Eddy

        Comment


        • #5
          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...

          Code:
          #COMPILE EXE 
          
          FUNCTION Foobar (<offending varname> AS <real type>) AS LONG
           FUNCTION = 0
          END FUNCTION
          
          ... REST OF PROGRAM HERE...
          ...
          MCM
          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Code:
            #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.
            Last edited by Michael Mattias; 1 Apr 2009, 06:48 AM.
            Michael Mattias
            Tal Systems Inc. (retired)
            Racine WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              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:
              Todd Wasson
              http://PerformanceSimulations.Com
              PowerBasic Racing Simulator (October 2007 clip - 15.1MB wmv file) http:http://www.performancesimulations.co...m-GenIV-12.wmv

              Comment


              • #8
                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.
                Michael Mattias
                Tal Systems Inc. (retired)
                Racine WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  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 :shhh:
                  Engineer's Motto: If it aint broke take it apart and fix it

                  "If at 1st you don't succeed... call it version 1.0"

                  "Half of Programming is coding"....."The other 90% is DEBUGGING"

                  "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                  Comment


                  • #10
                    Originally posted by Todd Wasson View Post
                    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

                    Comment


                    • #11
                      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...
                      Todd Wasson
                      http://PerformanceSimulations.Com
                      PowerBasic Racing Simulator (October 2007 clip - 15.1MB wmv file) http:http://www.performancesimulations.co...m-GenIV-12.wmv

                      Comment

                      Working...
                      X