MinGW - Minimalist GNU for Windows

"Paul G." <pgarceau@...> writes:

> after using the -shared switch and the -g switch.  The expected
> debug data itself, is not appearing when Mingw GDB is being used to
> debug certain .dlls which were generated using "g++ -shared -g ...".

-shared certainly generates debug data. Somehow gdb doesn't use it
 when you enter de dll. Try this:

1. Put a breakpoint on 'main'
2. Execute your app.
3. When it stops on 'main', put a breakpoint on some dll function.

When the execution reaches that function, you should see the source
code and everything else. Perhaps gdb doesn't load the dll debug info
until the main executable is initialized.

Then, there are some issues with C++ and g++/gdb. Seems most of them
are gone with g++ 3.2.2/gdb 5.2.1.

Take all this with a grain of salt, as I'm not a frequent gdb user.

-- 
Oscar

Thanks, Oscar, for your reply.

> "Paul G." <pgarceau@...> writes:
> 
> > after using the -shared switch and the -g switch.  The expected
> > debug data itself, is not appearing when Mingw GDB is being used to
> > debug certain .dlls which were generated using "g++ -shared -g ...".
> 
> -shared certainly generates debug data. Somehow gdb doesn't use it
>  when you enter de dll. Try this:
> 
> 1. Put a breakpoint on 'main'
> 2. Execute your app.
> 3. When it stops on 'main', put a breakpoint on some dll function.

	Ok.

	Does anyone know if there is some sort of predefined limit in terms of how much debug 
data can be loaded at any given time "in to" and "by" Mingw gdb?
> 
> When the execution reaches that function, you should see the source
> code and everything else. Perhaps gdb doesn't load the dll debug info
> until the main executable is initialized.
> 
> Then, there are some issues with C++ and g++/gdb. Seems most of them
> are gone with g++ 3.2.2/gdb 5.2.1.

	Where might I find a list of these particular issues?

> 
> Take all this with a grain of salt, as I'm not a frequent gdb user.

	Thanks again, Oscar.  Every little bit helps when there is a dearth of specific data or 
replies available.

	Paul G.
> 
> -- 
> Oscar
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> http://www.ictp.com/training/sourceforge.asp
> _______________________________________________ MinGW-users mailing
> list MinGW-users@...
> 
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users

"Paul G." <pgarceau@...> writes:

[snip]

> > Then, there are some issues with C++ and g++/gdb. Seems most of them
> > are gone with g++ 3.2.2/gdb 5.2.1.
> 
> 	Where might I find a list of these particular issues?

Maybe on the gdb bug database (if it exists at all) ? All I can say is
that g++ up to v3.2.2 was practically unusable for me with wathever
version of gdb. It ignored breakpoints on constructors (g++ v3 creates
two kinds of contructors for some classes: one for normal construction
and other for nested construction, i.e. when the constructor is called
from a derived class' constructor). Template code makes gdb crazy,
jumping to random places of source code again and again. It has
difficulties for inspecting data ('this' was reported as 'unknown
type'). From time to time it decides it's enough and terminates the
application being debugged.

All this was gone after upgrading to 3.2.2. But maybe it is related
with the nature of the project. I'm working on a different piece of
code now.

-- 
Oscar

> "Paul G." <pgarceau@...> writes:
> 
> [snip]
> 
> > > Then, there are some issues with C++ and g++/gdb. Seems most of
> > > them are gone with g++ 3.2.2/gdb 5.2.1.
> > 
> > 	Where might I find a list of these particular issues?
> 
> Maybe on the gdb bug database (if it exists at all) ?

	Think that is a valid point, "if it exists at all", I mean.  Cygwin version of Insight does not 
function in the same way that the Mingw tool called "gdb" does, so it is probably not a good 
resource to consider.

	As to gdb itself, specifically the Mingw tool, I have yet to see anything anywhere that 
talks much about what the issues actually are where Mingw built "tool", gdb, is concerned.

> All I can say is
> that g++ up to v3.2.2 was practically unusable for me with wathever
> version of gdb.

> It ignored breakpoints on constructors (g++ v3 creates
> two kinds of contructors for some classes: one for normal construction
> and other for nested construction, i.e. when the constructor is called
> from a derived class' constructor). Template code makes gdb crazy,
> jumping to random places of source code again and again. It has
> difficulties for inspecting data ('this' was reported as 'unknown
> type'). From time to time it decides it's enough and terminates the
> application being debugged.

	This last paragraph, by itself, is far more information about gdb than I have ever had 
before when I've attempted to bring it up.

	Thank you, Oscar.
> 
> All this was gone after upgrading to 3.2.2. But maybe it is related
> with the nature of the project. I'm working on a different piece of
> code now.

	Ok.

	Thanks again,

		Paul G.

On Wed, Feb 26, 2003 at 05:28:05PM -0800, Paul G. wrote:
>> "Paul G." <pgarceau@...> writes:
>> [snip]
>>>>Then, there are some issues with C++ and g++/gdb.  Seems most of them
>>>>are gone with g++ 3.2.2/gdb 5.2.1.
>>>
>>>Where might I find a list of these particular issues?
>>
>>Maybe on the gdb bug database (if it exists at all) ?
>
>Think that is a valid point, "if it exists at all", I mean.  Cygwin
>version of Insight does not function in the same way that the Mingw
>tool called "gdb" does, so it is probably not a good resource to
>consider.

The cygwin package which installs "insight" is called "gdb".  That
might be a clue that there is a command "gdb" which can be used
to debug programs the same way that the standalone version of gdb
debugs programs everywhere.

If you want a GUI debugger you should be able to just install
the "gdb" and "cygwin" packages via setup and that should operate
just fine on MinGW programs.  If you don't want a GUI debugger, at
least the version of gdb available on Cygwin is up-to-date.

cgf

On Fri, Feb 28, 2003 at 12:37:55AM -0500, Christopher Faylor wrote:
>On Wed, Feb 26, 2003 at 05:28:05PM -0800, Paul G. wrote:
>>> "Paul G." <pgarceau@...> writes:
>>> [snip]
>>>>>Then, there are some issues with C++ and g++/gdb.  Seems most of them
>>>>>are gone with g++ 3.2.2/gdb 5.2.1.
>>>>
>>>>Where might I find a list of these particular issues?
>>>
>>>Maybe on the gdb bug database (if it exists at all) ?
>>
>>Think that is a valid point, "if it exists at all", I mean.  Cygwin
>>version of Insight does not function in the same way that the Mingw
>>tool called "gdb" does, so it is probably not a good resource to
>>consider.
>
>The cygwin package which installs "insight" is called "gdb".  That
>might be a clue that there is a command "gdb" which can be used
>to debug programs the same way that the standalone version of gdb
>debugs programs everywhere.
>
>If you want a GUI debugger you should be able to just install
>the "gdb" and "cygwin" packages via setup and that should operate
>just fine on MinGW programs.  If you don't want a GUI debugger, at
>least the version of gdb available on Cygwin is up-to-date.

I used a lot of words above and still didn't make it clear that

1) The Cygwin gdb package contains two executables: insight.exe
   and gdb.exe.  insight is the GUI debugger, gdb is the standard
   command-line debugger.

2) Either of the above programs can be used to debug MinGW
   applications.

cgf

Thanks, Chris!

> On Fri, Feb 28, 2003 at 12:37:55AM -0500, Christopher Faylor wrote:
> >On Wed, Feb 26, 2003 at 05:28:05PM -0800, Paul G. wrote: >>> "Paul
> G." <pgarceau@...> writes: >>> [snip] >>>>>Then, there are some
> issues with C++ and g++/gdb.  Seems most of them >>>>>are gone with
> g++ 3.2.2/gdb 5.2.1. >>>> >>>>Where might I find a list of these
> particular issues? >>> >>>Maybe on the gdb bug database (if it exists
> at all) ? >> >>Think that is a valid point, "if it exists at all", I
> mean.  Cygwin >>version of Insight does not function in the same way
> that the Mingw >>tool called "gdb" does, so it is probably not a good
> resource to >>consider. > >The cygwin package which installs "insight"
> is called "gdb".  That >might be a clue that there is a command "gdb"
> which can be used >to debug programs the same way that the standalone
> version of gdb >debugs programs everywhere. > >If you want a GUI
> debugger you should be able to just install >the "gdb" and "cygwin"
> packages via setup and that should operate >just fine on MinGW
> programs.  If you don't want a GUI debugger, at >least the version of
> gdb available on Cygwin is up-to-date.
> 
> I used a lot of words above and still didn't make it clear that
> 
> 1) The Cygwin gdb package contains two executables: insight.exe
>    and gdb.exe.  insight is the GUI debugger, gdb is the standard
>    command-line debugger.
> 
> 2) Either of the above programs can be used to debug MinGW
>    applications.

	Ok, will remember their orientations then.

		Paul G.
> 
> cgf
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
> 
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users