Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: oBFusCATed on February 19, 2012, 06:15:15 pm

Title: Dr. Memory
Post by: oBFusCATed 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.
Title: Re: Dr. Memory
Post by: MortenMacFly 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!
Title: Re: Dr. Memory
Post by: oBFusCATed 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
Title: Re: Dr. Memory
Post by: oBFusCATed 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 :(
Title: Re: Dr. Memory
Post by: oBFusCATed 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.
Title: Re: Dr. Memory
Post by: Alpha 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.
Title: Re: Dr. Memory
Post by: oBFusCATed 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.
Title: Re: Dr. Memory
Post by: Alpha 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.
Title: Re: Dr. Memory
Post by: Alpha 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 (http://groups.google.com/group/dynamorio-users/browse_thread/thread/f0516382fcfba933)).
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)
 

Title: Re: Dr. Memory
Post by: oBFusCATed 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....
Title: Re: Dr. Memory
Post by: MortenMacFly 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.
Title: Re: Dr. Memory
Post by: MortenMacFly 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... ::)
Title: Re: Dr. Memory
Post by: oBFusCATed 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]
Title: Re: Dr. Memory
Post by: MortenMacFly 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).
Title: Re: Dr. Memory
Post by: oBFusCATed 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?
Title: Re: Dr. Memory
Post by: MortenMacFly on February 28, 2012, 10:30:19 am
Does TDM's g++ 4.5.x produce dwarf2 symbols?
I don't know about TDM's g++ 4.5.x, but TDM's g++ 4.6.x do (of course, you'll need to d/l the DWARF version).
Title: Re: Dr. Memory
Post by: oBFusCATed on February 28, 2012, 10:35:32 am
I think that I'm using the dw2 version of 4.5.x.
Title: Re: Dr. Memory
Post by: MortenMacFly on March 29, 2012, 07:54:49 am
I think that I'm using the dw2 version of 4.5.x.
OK - the final DrMemory release with official MinGW support is out. I did a small sample:
Code
#include <cstdlib> // malloc
#include <iostream>

void func2(int* the_old_i, int the_new_i)
{
  std::cout << "Now in func2!" << std::endl;
  *the_old_i = the_new_i;

  std::cout << "Now leaking " << sizeof(double) << " bytes w/ malloc..." << std::endl;
  double* d = static_cast<double*>( malloc(sizeof(double)) );
}

void func1(int* i)
{
  std::cout << "Calling func2()" << std::endl;
  func2(i, 42);

  std::cout << "Now leaking 42 bytes w/ malloc..." << std::endl;
  void* v = malloc(42);
}

int main(int argc, char **argv)
{
  std::cout << "Calling func1()" << std::endl;
  int* i = new int;
  func1(i);

  std::cout << "Now leaking " << sizeof(int) << " bytes w/ new..." << std::endl;

  return 0;
}
And that's the report I am getting:
Dr. Memory version 1.4.6 build 2 built on Mar  7 2012 10:14:04
Application cmdline: ""C:\Devel\DrMemory\bin\drmemory_test.exe""
Recorded 62 suppression(s) from default C:\Devel\DrMemory/bin/suppress-default.txt

Error #1: POSSIBLE LEAK 58 direct bytes 0x003f2cd0-0x003f2d0a + 0 indirect bytes
# 0 msvcrt.dll!lock     
# 1 msvcrt.dll!_getmainargs
# 2 __mingw_CRTStartup                     [../mingw/init.c:60]
# 3 mainCRTStartup                         [../mingw/crt1.c:264]
# 4 KERNEL32.dll!RegisterWaitForInputIdle

Error #2: LEAK 4 direct bytes 0x003f2e28-0x003f2e2c + 0 indirect bytes
# 0 operator new()   
# 1 main                         [C:\Devel\DevPacks\DrMemory\bin/drmemory_test.cpp:25]

Error #3: LEAK 8 direct bytes 0x003f2e58-0x003f2e60 + 0 indirect bytes
# 0 func2()                   [C:\Devel\DrMemory\bin/drmemory_test.cpp:10]
# 1 std::ws<>()     
# 2 func1()                   [C:\Devel\DrMemory\bin/drmemory_test.cpp:16]
# 3 main                      [C:\Devel\DrMemory\bin/drmemory_test.cpp:26]

Error #4: LEAK 42 direct bytes 0x003f2e88-0x003f2eb2 + 0 indirect bytes
# 0 func1()                   [C:\Devel\DrMemory\bin/drmemory_test.cpp:19]
# 1 std::ws<>()     
# 2 main                      [C:\Devel\DrMemory\bin/drmemory_test.cpp:26]

DUPLICATE ERROR COUNTS:

SUPPRESSIONS USED:

ERRORS FOUND:
      0 unique,     0 total unaddressable access(es)
      0 unique,     0 total uninitialized access(es)
      0 unique,     0 total invalid heap argument(s)
      0 unique,     0 total warning(s)
      3 unique,     3 total,     54 byte(s) of leak(s)
      1 unique,     1 total,     58 byte(s) of possible leak(s)
ERRORS IGNORED:
    202 still-reachable allocation(s)
         (re-run with "-show_reachable" for details)
Details: C:\Devel\DrMemory/drmemory/logs/DrMemory-drmemory_test.exe.6988.000/results.txt

Nice, isn't it???
Title: Re: Dr. Memory
Post by: ollydbg on March 29, 2012, 08:21:17 am
I think that I'm using the dw2 version of 4.5.x.
OK - the final DrMemory release with official MinGW support is out. I did a small sample:
Nice, isn't it???
VERY nice! I have never used it, I will try to download one from http://drmemory.googlecode.com/files/DrMemory-Windows-1.4.6-2.zip and test it.  :)