[OT] MinGW GCC 4.4 released!

[ollydbg]

I found in the Mingw user maillist.
I have only one question:

- Improved debugging information: Dwarf-2 debugging is now the default.
   Make sure to get the latest GDB version for the best debugging
   experience.

Seems Dwarf-2 format is better.

Here is the notes in TDM-GCC's readme file

*** Dwarf-2 vs. SJLJ unwinding ***

GCC supports two methods of stack frame unwinding: Dwarf-2 (DW2) or SJLJ
(setjmp/longjmp). Until recently, only SJLJ has been available for the Windows
platform. This affects you, the end user, primarily in programs that throw and
catch exceptions. Programs which utilize the DW2 unwind method handle exceptions
much more quickly than programs which utilize the SJLJ method. However, the DW2
method increases code size by a noticeable amount, and additionally cannot yet
unwind (pass exceptions) through "foreign" stack frames: stack frames compiled
by another non-DW2-enabled compiler, such as OS DLLs in a Windows callback.

This means that you should in general choose the SJLJ version of the TDM-GCC
builds unless you know you need faster exception handling and can be certain you
will never throw an exception through a foreign stack area.

As distributed, the SJLJ and DW2 packages of TDM-GCC can coexist peacefully
extracted to the same directory (e.g. any files in common are for all intents
and purposes identical), because the driver executables (the ones in the "bin"
directory) are suffixed with "-dw2" for the DW2 build, and the libraries and
other executables hide in another "-dw2" directory in "lib(exec)/gcc/mingw32".
This allows you to use the same single addition to your PATH, and use DW2
exceptions only when you need them by calling "gcc-dw2", etc. If you truly want
DW2 exceptions as the default when calling "gcc" (from Makefiles or configury
systems, for example), you can rename or copy the suffixed executables to their
original names.

Does it means that we can wholly transferred to DW2 (both building and debugging)?

Thanks.

[thomas]

Does it means that we can wholly transferred to DW2 (both building and debugging)?

You could do that all the time, only now it's apparently the default in MinGW from what you quoted. I'm using DW2 for years. However, it means that you can't catch exeptions that come from proprietary third party libraries. If this doesn't bother you (it doesn't bother me), there's no difference except exception handling is much faster.

[ollydbg]

@thomas
Thanks for the explanation!!!

[killerbot]

AFter using TDM GCC 4.4.0, I will give this one a try, and when I am able to build CB nicely and use it nicely (which I could with TDM GCC 4.4.0) I will switch nightlies to this GCC version.

[ollydbg]

After manually install (unpack all the zip file to the same folder) this MinGW version, I successfully built CB svn version.
Seems CB works nicely, no bug was found till now.

[ollydbg]

oh, my God, we still can't set breakpoints in header file when debugging in CB .

Seems this bug has fixed in TDM-GCC, but still exists in Offical MinGW 4.4.0.

See the description:

https://sourceforge.net/tracker/?func=detail&aid=2145427&group_id=200665&atid=974439

By the way:

Is there any way I can report to Official MinGW dev Team?
or it is already in bug tracker.

[stahta01]

Is there any way I can report to Official MinGW dev Team?
or it is already in bug tracker.

Report Bugs directions here: http://www.mingw.org/bugs.shtml
http://sourceforge.net/tracker/?group_id=2435&atid=102435

I have never reported a bug; note submitting a patch is very hard to do right; I tried once.
( A lot of MinGW Code is Public Domain which means you can not submit GPL code in some cases.)

Tim S

[ollydbg]

I have reported in MinGW user maillist. Hopefully they can get attention.

By the way:

Problem setting a breakpoint in a header file.

Steps to demonstrate the problem:

(1) Create and move to directory C:\CB

(2) Create header file Function.h
    inline int Fcn1()
    {
        return 1;
    }

(3) Create source file main.cpp
    #include "Function.h"
    int main()
    {
        int A = Fcn1();
        A *= 2;
        return 0;
    }

(4) Open a command window

(5) Compile with following (note backslashes in filename as used by CodeBlocks in Windows)
gcc -g  C:\CB\main.cpp -o CB.exe

(6) Launch debugger
gdb CB.exe

(7) Try to set breakpoint in header
(gdb) b C:\CB\Function.h:3
   and get error
No source file named C:\CB\Function.h in loaded symbols.

( Quit debugger, erase CB.exe and recompile with following (note forward slashes)
gcc -g  C:/CB/main.cpp -o CB.exe

(9) Launch debugger
gdb CB.exe

(10) Again try to set breakpoint in header
(gdb) b C:\CB\Function.h:3
   and this time successfully get
Breakpoint 1 at 0x4017db: file C:/CB/Function.h, line 3.

Why not we use "forward slashed" in CB to skip this bug? 

[stahta01]

AFter using TDM GCC 4.4.0, I will give this one a try, and when I am able to build CB nicely and use it nicely (which I could with TDM GCC 4.4.0) I will switch nightlies to this GCC version.

@killerbot
Please look at using this patch if you change the Compiler to 4.4 DW2
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2780&group_id=5358

It creates the exchndl.dll that creates the codeblocks.RPT under windows. The old exchndl.dll only seems to work well with 3.4.5 SJLJ Compiler.

Tim S