Author Topic: Dr. Memory  (Read 27199 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Dr. Memory
« on: February 19, 2012, 06:15:15 pm »
Hi,

Have anyone had any success with running Codeblocks or any other executable compiled with MinGW?
I've just installed it, but I don't see the stack frames for my code.
I've read something about using the cygwin version, instead of the normal windows version, but I'm not really sure, what should I do.
Any help will be welcomed.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9723
Re: Dr. Memory
« Reply #1 on: February 19, 2012, 07:43:51 pm »
Any help will be welcomed.
For MinGW support I'm afraid you'll need the repository version and compile it yourself - but its easy!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Dr. Memory
« Reply #2 on: February 19, 2012, 07:54:15 pm »
If it works I don't mind trying to compile it:)

Any tutorial or link explaining the whole process?

edit: I hope this http://code.google.com/p/drmemory/wiki/HowToBuild will be enough
« Last Edit: February 19, 2012, 08:01:59 pm by oBFusCATed »
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Dr. Memory
« Reply #3 on: February 19, 2012, 10:26:52 pm »
Morten: Is there a chance to send me a binary of DrMemory with mingw support?
I've downloaded tons of stuff and I've not started building.
Downloading stuff from M$ sites is a nightmare :(
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Dr. Memory
« Reply #4 on: February 20, 2012, 01:34:41 am »
Code
uzer@xlad /cygdrive/c/dev/drmemory/build
$ cmake -G"Visual Studio 9 2008" -DCMAKE_BUILD_TYPE=Release ../
-- Dr. Memory version number: 1.4.761
-- Found ntdll.lib: C:/WinDDK/6000/lib/w2k/i386/ntdll.lib
-- Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE)
doxygen is required to build the documentation
-- Building DynamoRIO from local sources C:/dev/drmemory/build/dynamorio/cmake
-- Found MinGW gcc at C:/MinGW32/bin/mingw32-g++.exe
-- Version number: 3.1.1264
CMake Error at dynamorio/CMakeLists.txt:479 (message):
  assembler not found: required to build


-- Configuring incomplete, errors occurred!
How am I supposed to fix this error?
I have as.exe and it seems to be working.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Dr. Memory
« Reply #5 on: February 20, 2012, 03:43:05 am »
I have worked with CMake a bit recently, and have several ideas that may help.

Assuming it is MinGW (not MSVC) you are trying to compile with, change your command to:
Code
cmake -G"MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release ../

Run this command from within Command Prompt (cmd.exe) - not MSYS, and not Cygwin.

Ensure all the binary tools you are using are accessible from the path (if, for example, you wanted Doxygen).

Configure in an interactive mode using:
Code
cmake -i -G "MinGW Makefiles" ../
After completing this, it may be necessary to run the following:
Code
cmake -G "MinGW Makefiles" ../
once before executing
Code
mingw32-make

Open the file CMakeCache.txt, the variables to better match your configuration, and rerun:
Code
cmake -G "MinGW Makefiles" ../


(Slightly unrelated...)
On the topic of CMake, I have noticed that CC populates the suggestions (with keywords) for *.cmake files, but not for *CMakeLists.txt files; conversely, the lexer is able to use these wildcards to accurately provide syntax highlighting in both situations.  (I am currently working on a CMake lexer.)
I was wondering if anyone had a suggestion of what discrepancy could be causing this/where I should look in Code::Blocks' source.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Dr. Memory
« Reply #6 on: February 20, 2012, 09:00:01 am »
Alpha: If you've never build Dr.Memory, your generic comment is useless.

Also CC does no syntax highlight, it is done by the wxScintilla.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Dr. Memory
« Reply #7 on: February 20, 2012, 05:59:07 pm »
Alpha: If you've never build Dr.Memory, your generic comment is useless.
My apologies; I misread what your question was.

Also CC does no syntax highlight, it is done by the wxScintilla.
Yes - this is what I was referring to.  Both mechanisms use the same lexer xml files to determine what to do, however the method by which wxScintilla appears to be using the file wildcards seems to be more effective than CC; I was wondering if there was any reasoning behind this that I have not foreseen, and also if there were any suggestions how I may alter this.

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Dr. Memory
« Reply #8 on: February 21, 2012, 11:33:12 pm »
Oh dear, I have realized that what I first wrote could be interpreted that I rudely implied I thought you understood very little about the concept of using CMake.  So again, I apologize.

If you have not already figured out a solution, perhaps the following patch will aid you with fixing the build system of the DynamoRIO dependency (which apparently has not yet been ported to MinGW).
Code
Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt (revision 1264)
+++ CMakeLists.txt (working copy)
@@ -408,7 +408,7 @@
 ###########################################################################
 # toolchain
 
-if (UNIX)
+if (UNIX OR MINGW)
 
   # Assume clang behaves like gcc.  CMake 2.6 won't detect clang and will set
   # CMAKE_COMPILER_IS_GNUCC to TRUE, but 2.8 does not.  We prefer the 2.6
@@ -440,7 +440,7 @@
   # detect it.
   string(REGEX MATCH "clang" CMAKE_COMPILER_IS_CLANG "${CMAKE_C_COMPILER}")
 
-else (UNIX)
+else (UNIX OR MINGW)
 
   if (NOT ${COMPILER_BASE_NAME} STREQUAL "cl")
     # we use cl pragmas and intrinsics
@@ -535,14 +535,14 @@
   get_filename_component(NTDLL_LIBPATH "${NTDLL_LIBPATH}" PATH)
   link_directories(${NTDLL_LIBPATH})
 
-endif (UNIX)
+endif (UNIX OR MINGW)
 
 find_package(Perl)
 if (NOT PERL_FOUND)
   message(FATAL_ERROR "perl is required to build")
 endif (NOT PERL_FOUND)
 
-if (UNIX) # unlikely to be an issue on Windows
+if (UNIX OR MINGW) # unlikely to be an issue on Windows
   # Check for uint, etc. typedef conflicts like on rhel3 (i#18)
   # and set DR_DO_NOT_DEFINE_*
   # Note that for later gcc uint and ushort seem to be "soft typedefs":
@@ -571,13 +571,13 @@
       message(FATAL_ERROR "incompatible \"_Bool\" type is larger than 1 byte")
     endif (NOT ${DR__Bool_EXISTS} EQUAL 1)
   endif (DR__Bool_EXISTS)
-endif (UNIX)
+endif (UNIX OR MINGW)
 
 ###########################################################################
 # basic build rules and flags
 
 # compiler flags
-if (UNIX)
+if (UNIX OR MINGW)
   # -std=c99 doesn't quite work
   # FIXME case 191480: we used to pass -pedantic just to cpp;
   # now w/ no separate cpp step we should eliminate the
@@ -603,7 +603,7 @@
     set(ASM_FLAGS "${ASM_FLAGS} -g")
   endif (DEBUG)
   # there's no cmake warning control so we hardcode it
-  set(WARN "-Wall -Werror")
+  set(WARN "-Wall")
   if (NOT CMAKE_COMPILER_IS_CLANG)
     # Old gcc's ignore unknown -W flags, but -Wall -Werror causes clang to
     # complain that it doesn't recognize it.
@@ -638,7 +638,7 @@
   set(CPP_NO_LINENUM -P)
   set(CPP_KEEP_WHITESPACE -traditional-cpp)
   set(CMAKE_CPP_FLAGS "")
-else (UNIX)
+else (UNIX OR MINGW)
   # FIXME: why isn't ${CMAKE_CL_NOLOGO} set?
   set(BASE_CFLAGS "/nologo")
   # build in parallel, always.
@@ -685,19 +685,19 @@
   set(CMAKE_CPP_FLAGS "/nologo")
   set(ASM_FLAGS "/nologo ${ASM_DBG}")
   set(BASE_CXXFLAGS "${BASE_CFLAGS}")
-endif (UNIX)
+endif (UNIX OR MINGW)
 
-if (UNIX)
+if (UNIX OR MINGW)
  # i#646: cmake 2.8.5 requires ASM-ATT to find as: but we don't want to change
  # all our vars to have -ATT suffix so we set the search list instead
  set(CMAKE_ASM_COMPILER_INIT gas as)
-endif (UNIX)
+endif (UNIX OR MINGW)
 enable_language(ASM)
 # note that I had to fix a bug in /usr/share/cmake/Modules/CMakeASMInformation.cmake
 # where @VAR@ expansion was used, which only works for configure_file()
 #   now fixed in CMake/Modules/CMakeASMInformation.cmake:1.5
 # see above for our workaround
-if (UNIX)
+if (UNIX OR MINGW)
   # we used to have ".ifdef FOO" and to not have it turn into ".ifdef 1" we'd say
   # "-DFOO=FOO", but we now use exclusively preprocessor defines, which is good
   # since our defines are mostly in configure.h where we can't as easily tweak them
@@ -720,7 +720,7 @@
     # comes up empty for me.
     "<CMAKE_ASM_COMPILER> ${ASM_FLAGS} -o <OBJECT> <OBJECT>.s"
     )
-else (UNIX)
+else (UNIX OR MINGW)
   # Even if we didn't preprocess we'd need our own rule since cmake doesn't
   # support ml.
   set(CMAKE_ASM_COMPILE_OBJECT
@@ -736,9 +736,9 @@
     "<CMAKE_COMMAND> -Dfile=<OBJECT>.s -P \"${PROJECT_SOURCE_DIR}/make/CMake_asm.cmake\""
     "<CMAKE_ASM_COMPILER> ${ASM_FLAGS} /c /Fo<OBJECT> <OBJECT>.s"
     )
-endif (UNIX)
+endif (UNIX OR MINGW)
 
-if (UNIX)
+if (UNIX OR MINGW)
   # We require gas >= 2.18.50 for --32, --64, and the new -msyntax=intel, etc.
   # Since this is pretty recent we include a copy (built vs as old a glibc
   # as was convenient)
@@ -878,7 +878,7 @@
     endif (NOT flag_present)
   endif (EXISTS ${CMAKE_OBJCOPY} AND EXISTS ${CMAKE_STRIP})
 
-endif (UNIX)
+endif (UNIX OR MINGW)
 
 # Should we be using fewer of these and using cmake's Debug vs Release?
 #   Release => -O3 -NDEBUG
Index: make/CMake_events.cmake
===================================================================
--- make/CMake_events.cmake (revision 1264)
+++ make/CMake_events.cmake (working copy)
@@ -48,16 +48,28 @@
   )
 if (WIN32)
   set(EVENTS_SRCS ${PROJECT_BINARY_DIR}/events.h)
-  set_source_files_properties(${EVENTS_SRCS} PROPERTIES GENERATED true)
+  set_source_files_properties(${EVENTS_SRCS} PROPERTIES GENERATED true)
+  if (MINGW)
   add_custom_command(
     OUTPUT ${EVENTS_SRCS}
     DEPENDS ${PROJECT_SOURCE_DIR}/core/win32/events.mc
+      COMMAND ${PERL_EXECUTABLE}
+      ARGS ${PROJECT_SOURCE_DIR}/core/gen_event_strings.pl
+           ${PROJECT_SOURCE_DIR}/core/win32/events.mc
+           ${EVENTS_SRCS}
+      VERBATIM # recommended: p260
+    )
+  else (MINGW)
+    add_custom_command(
+      OUTPUT ${EVENTS_SRCS}
+      DEPENDS ${PROJECT_SOURCE_DIR}/core/win32/events.mc
     COMMAND ${CMAKE_MC_COMPILER}
     ARGS -h ${PROJECT_BINARY_DIR}
          -r ${PROJECT_BINARY_DIR}
          ${PROJECT_SOURCE_DIR}/core/win32/events.mc
     VERBATIM # recommended: p260
-  )
+    )
+  endif (MINGW)
 else (WIN32)
   set(EVENTS_SRCS "")
 endif (WIN32)
Index: make/DynamoRIOConfig.cmake.in
===================================================================
--- make/DynamoRIOConfig.cmake.in (revision 1264)
+++ make/DynamoRIOConfig.cmake.in (working copy)
@@ -197,7 +197,15 @@
   else (is_cxx)
     set(sizeof_void ${CMAKE_C_SIZEOF_DATA_PTR})
   endif (is_cxx)
-
+
+# { hack
+
+  if (MINGW)
+    set(sizeof_void 8)
+  endif (MINGW)
+
+#   end hack
+# }
   if ("${sizeof_void}" STREQUAL "")
     message(FATAL_ERROR "unable to determine bitwidth: did earlier ABI tests fail?  check CMakeFiles/CMakeError.log")
   endif ("${sizeof_void}" STREQUAL "")
@@ -358,7 +366,7 @@
   get_size(${tgt_cxx} tgt_x64)
   DynamoRIO_extra_cflags(tgt_cflags "${tgt_cflags}" ${tgt_cxx})
 
-  if (UNIX)
+  if (UNIX OR MINGW)
     if (is_client)
 
       if (NOT DEFINED DynamoRIO_VISATT)
@@ -397,7 +405,7 @@
     endif (is_client)
     # gcc is invoked for the link step so we have to repeat cflags as well
     set(tgt_link_flags "${tgt_cflags} ${tgt_link_flags}")
-  else (UNIX)
+  else (UNIX OR MINGW)
     if (tgt_cxx)
       set(tgt_cflags "${tgt_cflags} /EHsc")
     endif (tgt_cxx)
@@ -427,7 +435,7 @@
         set(tgt_link_flags "${tgt_link_flags} /nodefaultlib /noentry")
       endif (tgt_cxx)
     endif (is_client)
-  endif (UNIX)
+  endif (UNIX OR MINGW)
 
   # DynamoRIOTarget.cmake added the "dynamorio" imported target
   target_link_libraries(${target} dynamorio)
@@ -483,7 +491,11 @@
     endforeach (config)
     set(DynamoRIO_configured_globally ${DynamoRIO_configured_globally} PARENT_SCOPE)
   endif (just_configured)
-
+# { hack
+set(DynamoRIO_SET_PREFERRED_BASE OFF)
+set(tgt_x64 FALSE)
+# end hack
+# }
   if (tgt_x64 OR DynamoRIO_SET_PREFERRED_BASE)
     # While we now have private loaders that mean we don't need a preferred
     # base in the lower 2GB, on Windows it's more efficient to avoid
@@ -493,12 +505,16 @@
     if (NOT DEFINED PREFERRED_BASE)
       set(PREFERRED_BASE 0x72000000)
     endif ()
-    if (UNIX)
+    if (UNIX OR MINGW)
       # We use a linker script to set the preferred base
       set(LD_SCRIPT ${CMAKE_CURRENT_BINARY_DIR}/ldscript)
       # We do NOT add ${LD_SCRIPT} as an ADDITIONAL_MAKE_CLEAN_FILES since it's
       # configure-time built not make-time built
-      set(LD_FLAGS "-melf_x86_64")
+      if (MINGW)
+        set(LD_FLAGS "-mi386pe")
+      else (MINGW)
+        set(LD_FLAGS "-melf_x86_64")
+      endif (MINGW)
 
       # In order to just tweak the default linker script we start with exactly that.
       execute_process(COMMAND
@@ -526,9 +542,9 @@
       # -dT is preferred, available on ld 2.18+: we could check for it
       set(LD_SCRIPT_OPTION "-T")
       set(PREFERRED_BASE_FLAGS "-Xlinker ${LD_SCRIPT_OPTION} -Xlinker \"${LD_SCRIPT}\"")
-    else (UNIX)
+    else (UNIX OR MINGW)
       set(PREFERRED_BASE_FLAGS "/base:${PREFERRED_BASE} /dynamicbase:no")
-    endif (UNIX)
+    endif (UNIX OR MINGW)
     set(tgt_link_flags "${tgt_link_flags} ${PREFERRED_BASE_FLAGS}")
   endif (tgt_x64 OR DynamoRIO_SET_PREFERRED_BASE)
 


Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Dr. Memory
« Reply #9 on: February 21, 2012, 11:45:00 pm »
Oh dear, I have realized that what I first wrote could be interpreted that I rudely implied I thought you understood very little about the concept of using CMake.  So again, I apologize.
Don't worry, too much. Your assumption is 90% right. I don't know anything about CMake apart from being crappy software which many people like and use for unknown reason. :)

Can anyone who has successfully built the Dr.Memory post the full command list here.
Because the build description on their site has too many assumption for a person who is new to cygwin+cmake+vc+++wdk+some more crap....
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9723
Re: Dr. Memory
« Reply #10 on: February 22, 2012, 07:29:43 am »
Can anyone who has successfully built the Dr.Memory post the full command list here.
I used it as described here:
http://groups.google.com/group/drmemory-users/browse_thread/thread/bd0eb2b0d580d04f

However, my experience is limited as it was simply too slow for large scale applications.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9723
Re: Dr. Memory
« Reply #11 on: February 22, 2012, 07:44:18 am »
...btw, I just realised that they have a new build:
http://code.google.com/p/drmemory/downloads/detail?name=DrMemory-Windows-1.4.5-2.zip

So I downloaded it, installed and tried with a console application compiled using MinGW. It works! You need to run the console application inside a cmd.exe environment as simple as:
C:\Devel\DrMemory\bin>drmemory.exe -- MyLeakTest.exe
I added two memory leaks and I got both of them reported correctly (and a faulty one). The console application crashes in the end, but besides that its OK.

...maybe I guided you in the wrong direction in the first place... ::)
« Last Edit: February 22, 2012, 07:47:58 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Dr. Memory
« Reply #12 on: February 22, 2012, 08:48:57 am »
I'm using this version and I don't see the symbols inside my testing executable (build with mingw).
Are you sure it works for you?

Here is the output from the mingw compiled executable.
Code
Error #1: POSSIBLE LEAK 268 direct bytes 0x00361150-0x0036125c + 0 indirect bytes
# 0 msvcrt.dll!strcpy_s 
# 1 msvcrt.dll!clearerr_s
# 2 msvcrt.dll!clearerr_s
# 3 drmemory_test.exe!?               
# 4 drmemory_test.exe!?               
# 5 KERNEL32.dll!BaseThreadInitThunk
# 6 ntdll.dll!RtlInitializeExceptionChain
# 7 ntdll.dll!RtlInitializeExceptionChain

Error #2: LEAK 40 direct bytes 0x00361378-0x003613a0 + 0 indirect bytes
# 0 drmemory_test.exe!?               
# 1 drmemory_test.exe!?               
# 2 drmemory_test.exe!?               
# 3 drmemory_test.exe!?               
# 4 drmemory_test.exe!?               
# 5 KERNEL32.dll!BaseThreadInitThunk
# 6 ntdll.dll!RtlInitializeExceptionChain
# 7 ntdll.dll!RtlInitializeExceptionChain

Here is what I get if I use vc9 instead of mingw
Code
Error #1: LEAK 40 direct bytes 0x004d45d0-0x004d45f8 + 0 indirect bytes
# 0 operator new                              [f:\dd\vctools\crt_bld\self_x86\crt\src\new.cpp:59]
# 1 main                                      [c:\dev\projects\tests\drmemory_test\main.cpp:7]
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9723
Re: Dr. Memory
« Reply #13 on: February 28, 2012, 09:04:50 am »
I'm using this version and I don't see the symbols inside my testing executable (build with mingw).
Are you sure it works for you?
This version works:
http://drmemory.org/DrMemory-Windows-1.4.6-1.zip

However, you'll need to compile your stuff with a DWARF2 based compiler (not sure if you did).
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: Dr. Memory
« Reply #14 on: February 28, 2012, 10:11:23 am »
OK, I'll try it the next time I restart to windows.
Does TDM's g++ 4.5.x produce dwarf2 symbols?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]