Is this information correct?

Is this information correct?

[Carlo Wood]

In the next release of libcwd (http://libcwd.sourceforge.net)
I will add the information below.

Because this will reach a few hunderd C++ developers, I wanted
to check with you if this information is correct in your eyes.
Any improvement is welcomed.

-------
A core dump produced by a kernel 2.4 does not
contain enough information for gdb to debug all
threads.  Only the core dumping thread is dumped
and the other threads continue to run for a while.
There exists a kernel patch written by Intel/IBM
that fixes this problem; please read
http://www.apachelabs.org/lkml/200203.mbox/%3c20020315170726.A3405@in.ibm.com%3e
or
http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.1/0963.html

You are strongly advised to use gdb 5.2 for multithreaded
debugging; however, it may be possible that the released
gdb 5.2 is not capable of reading the debug information
that is used by gcc 3.1, I heard (libcwd needed to be fixed
too), the latest CVS version of gdb works though.

Be aware that gdb does hardly support namespaces and
will therefore frequently not find types or variables
in namespaces.  It doesn't look like that this will be
fixed very soon (2002-05-27).
--------

-- 
Carlo Wood <carlo@alinoe.com>

Re: Is this information correct?

[Daniel Jacobowitz]

On Mon, May 27, 2002 at 02:20:06PM +0200, Carlo Wood wrote:
> In the next release of libcwd (http://libcwd.sourceforge.net)
> I will add the information below.
> 
> Because this will reach a few hunderd C++ developers, I wanted
> to check with you if this information is correct in your eyes.
> Any improvement is welcomed.
> 
> -------
> A core dump produced by a kernel 2.4 does not
> contain enough information for gdb to debug all
> threads.  Only the core dumping thread is dumped
> and the other threads continue to run for a while.
> There exists a kernel patch written by Intel/IBM
> that fixes this problem; please read
> http://www.apachelabs.org/lkml/200203.mbox/%3c20020315170726.A3405@in.ibm.com%3e
> or
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.1/0963.html

This part's fine.

> You are strongly advised to use gdb 5.2 for multithreaded
> debugging; however, it may be possible that the released
> gdb 5.2 is not capable of reading the debug information
> that is used by gcc 3.1, I heard (libcwd needed to be fixed
> too), the latest CVS version of gdb works though.

What's this part about though?  I think it's really referring to gdb
5.1 instead.  5.2 should be fine.

> Be aware that gdb does hardly support namespaces and
> will therefore frequently not find types or variables
> in namespaces.  It doesn't look like that this will be
> fixed very soon (2002-05-27).
> --------
> 
> -- 
> Carlo Wood <carlo@alinoe.com>

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Is this information correct?

[Carlo Wood]

On Mon, May 27, 2002 at 02:07:21PM -0400, Daniel Jacobowitz wrote:
> What's this part about though?  I think it's really referring to gdb
> 5.1 instead.  5.2 should be fine.

That was because of this chat I had on IRC:

[03:04] <`Kernel`> Run: not really. I had been awaiting 3.1 to remake world, but unfortunately preliminary tests showed that it outputs crap debug info.
[03:05] <Run> I can't believe that.
[03:05] <Run> Actually, it works fine for me.
[03:05] <`Kernel`> well, on the project I tested with, gdb 5.2 can't find some of the source files.
[03:06] <Run> I have no problems, also using gdb 5.2
[03:06] <`Kernel`> it works perfectly if you switch CXX=g++-3.0.4 instead of g++-3.1
[03:06] <Run> Oh wait
[03:06] <`Kernel`> (and it also says that main() is in some .h)
[03:06] <Run> I had to fix libcwd too because they switched from DW_FORM_string to DW_FORM_strp (pointers into a string table) for source files and directory names.
[03:07] <Run> That could be the reason.
[03:07] <`Kernel`> it could be the reason gdb fails?
[03:07] <Run> I am using the lastest cvs version of gdb, and that works.
[03:07] <Run> yes, because it was changed since 3.1, and it WOULD fuck up the source files
[03:08] <`Kernel`> hmm... ok, I'll try that. Altough gdb 5.2 if I am not mistaken was out May 14, one day before gcc 3.1.


I'll ask `Kernel` if moving to the cvs version of gdb
does help him.

-- 
Carlo Wood <carlo@alinoe.com>

Re: Is this information correct?

[Carlo Wood]

On Mon, May 27, 2002 at 02:07:21PM -0400, Daniel Jacobowitz wrote:
> What's this part about though?  I think it's really referring to gdb
> 5.1 instead.  5.2 should be fine.

Blah, its 6:30 am now... but we figured out what it was.
It was not gdb's fault, nor gcc's fault.  The "problem"
was that he was using -O2 and setting a break point
for main causes the break point to be set 4 bytes behond
'main' (the function pointer) which was already at the
start of some inlined constructor for which is was not
clear that it would be there (-O2 magic etc).
Anyway, my (independantly from gdb written) libcwd gave
exactly the same source file line number info ;).

I'll remove the remark that gdb-5.2 might not work with
g++ 3.1.  It works.

-- 
Carlo Wood <carlo@alinoe.com>

Re: Is this information correct?

[Andrew Cagney]

> On Mon, May 27, 2002 at 02:07:21PM -0400, Daniel Jacobowitz wrote:
> 
>> What's this part about though?  I think it's really referring to gdb
>> 5.1 instead.  5.2 should be fine.
> 
> 
> Blah, its 6:30 am now... but we figured out what it was.
> It was not gdb's fault, nor gcc's fault.  The "problem"
> was that he was using -O2 and setting a break point
> for main causes the break point to be set 4 bytes behond
> 'main' (the function pointer) which was already at the
> start of some inlined constructor for which is was not
> clear that it would be there (-O2 magic etc).
> Anyway, my (independantly from gdb written) libcwd gave
> exactly the same source file line number info ;).

Can I suggest adding a more generic comment about avoiding ``-O2'' and 
``-fomit-frame-pointer''.  GD should be able to handle these cases but 
(typically) it can't.  A known limitation in GDB (i.e. a bug :-).

enjoy,
Andrew