Re: [Mingw-users] Memory Debugging Tools for MinGW

[David E. <cr...@um...>]

On Tue, 22 Jul 2003, Greg Chicares wrote:
> Looks like you're inducing a deliberate error by writing
> to rndm[8], where the subscript eight refers to the ninth
> byte in an eight-byte array. Calling strdup() and not
> freeing the pointer it returns then causes a memory leak
> (which mpatrol can detect with the right options) but I
> don't see why it would obliterate the first error.

Correct on all counts.  It's an mpatrol issue -- I was able
to reproduce it on other platforms.  For some reason, the
error is detected with OFLOWSIZE == 0 when the strdup call
is not present.  But if I set OFLOWSIZE to 2, say, it detects
the error even with the strdup call.  Thanks.



A related question.  I'm trying to see if I can get Purify for Windows
to instrument MinGW generated executables.

If I build a simple console app with Visual Studio .NET (after
twiddling with some of the project settings to make Purify happy), I can
get purify to instrument it.  One of the linker switches needed
is /fixed:no, which seems to add a ".reloc" section to the resulting
executable.

If I build the same test app with gcc (MinGW version), purify complains:
"Warning: Code detected but missing .reloc section. Unable to instrument
module as requested. Module will be instrumented in Minimal mode."

Here's what objdump has to say, first for the Visual Studio generated
executable:

  $ objdump.exe -h Testolla.exe

  Testolla.exe:     file format pei-i386

  Sections:
  Idx Name          Size      VMA       LMA       File off  Algn
    0 .text         0000d000  00401000  00401000  00001000  2**4
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
    1 .rdata        00002000  0040e000  0040e000  0000e000  2**2
                    CONTENTS, ALLOC, LOAD, READONLY, DATA
    2 .data         00001000  00410000  00410000  00010000  2**4
                    CONTENTS, ALLOC, LOAD, DATA
    3 .reloc        00001000  00412000  00412000  00011000  2**2
                    CONTENTS, ALLOC, LOAD, READONLY, DATA, DEBUGGING


. . . and for the gcc generated executable:

  $ objdump.exe -h t.exe

  t.exe:     file format pei-i386

  Sections:
  Idx Name          Size      VMA       LMA       File off  Algn
    0 .text         00000600  00401000  00401000  00000400  2**4
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
    1 .data         00000200  00402000  00402000  00000a00  2**4
                    CONTENTS, ALLOC, LOAD, DATA
    2 .idata        00000400  00403000  00403000  00000c00  2**2
                    CONTENTS, ALLOC, LOAD, DATA

As you can see, there's no .reloc section.


I tried adding -Wl,--emit-relocs when I compiled . . .

   -q
   --emit-relocs
       Leave relocation sections and contents in fully linked exececutables.
       Post link analysis and optimization tools may need this
       information in order to perform correct modifications of executables.
       This results in larger executables.

       This option is currently only supported on ELF platforms.

but, as I'm not generating ELF, it didn't do anything, as advertised.


Any other ideas?  Thanks.

-David