* Re: RFC c++ debugging thread (fwd)
[not found] <Pine.SOL.3.91.1010702120615.3597C-100000@taarna.cygnus.com>
@ 2001-07-02 16:18 ` Jim Blandy
2001-07-02 16:58 ` Daniel Berlin
2001-07-04 5:15 ` Carlo Wood
0 siblings, 2 replies; 5+ messages in thread
From: Jim Blandy @ 2001-07-02 16:18 UTC (permalink / raw)
To: Carlo Wood; +Cc: gdb
Hi, Carlo. Ben Kosnik forwarded your message to me. I've taken the
liberty of CC'ing the GDB discussion mailing list on this reply; hope
that's okay.
> ---------- Forwarded message ----------
> Date: Sat, 30 Jun 2001 17:44:03 +0200
> From:
> To: Benjamin Kosnik <bkoz@redhat.com>
> Cc: libstdc++@gcc.gnu.org
> Subject: Re: RFC c++ debugging thread
>
> On Fri, Jun 29, 2001 at 12:00:34PM -0700, Benjamin Kosnik wrote:
> >
> > Hey C++ people. The gdb folks are doing inventory on C++ support in
> > the debugger. People who use gdb with C++ should probably scope this
> > thread and add constructive comments:
> >
> > http://sources.redhat.com/ml/gdb/2001-06/msg00219.html
> >
> > -benjamin
>
> If you can pass this on:
>
> 1) When typing expressions that have a scope, it is extremely annoying that the current
> scope is often not known to gdb - especially the lack of namespace support is annoying.
> I am using anonymous namespaces frequently and that makes it impossible to set
> break-points other than by line number.
> I think that when gdb is in a function 'A::(unamed)::C::f()', and I ask for 'g()', it should
> use the same lookup as the compiler: "(gdb) b g" should set a break point in the same
> function as that is called when I'd have had: "void A::(unnamed)::C::f(void) { g(); }".
> The ideal situation being that using an expression that appears after a 'list' command
> of the current scope will resolve to the correct expression. Another example being
> that in my current project ALL code that I am debugging is in namespace 'libcw::debug',
> so why do I constantly have to type: b 'libcw::debug::foo'? I'd like to just type:
> "(gdb) b foo" (assuming the current code is in scope 'libcw::debug' thus).
Our current understanding is that the namespace lossage is the most
immediately annoying problem, so that's what we'd like to fix first.
We have test cases for some problems, and although your problem sounds
similar, I can't be sure it's exactly the same problem you are seeing.
Could you put together a test case, show us what GDB does, and tell us
what you wish it did? Post to gdb@sources.redhat.com.
> 2) The 'next' command often doesn't work: it just finishes the whole program. I therefore
> have to use 'step' more often then I like, resulting in entering functions I don't
> want to enter (like libstdc++/STL stuff). I don't know why/when this happens, but
> it seems to happen often when returning from a function (on a '}' of a function that
> I am exiting, I *always* type 's' to avoid losing the trace).
> 3) Often wrong source-file:line-numbers are given. This might be a bug in the compiler.
> 4) Not all mangled names are demangled, and obviously the qualifiers are demangled wrongly,
> assuming you use libiberty's demangler then I suppose this will be fixed. I'll get back
> to this after my own demangler finally works (I am working on getting adding of
> substitutions right now).
Again, these sound like something we know about, but I'm not sure. If
you can provide a test case, that makes it much easier for us to be
sure we've actually fixed what's bothering you.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC c++ debugging thread (fwd)
2001-07-02 16:18 ` RFC c++ debugging thread (fwd) Jim Blandy
@ 2001-07-02 16:58 ` Daniel Berlin
2001-07-04 5:15 ` Carlo Wood
1 sibling, 0 replies; 5+ messages in thread
From: Daniel Berlin @ 2001-07-02 16:58 UTC (permalink / raw)
To: Jim Blandy, Carlo Wood; +Cc: gdb
--On Monday, July 02, 2001 6:19 PM -0500 Jim Blandy
<jimb@zwingli.cygnus.com> wrote:
>
> Hi, Carlo. Ben Kosnik forwarded your message to me. I've taken the
> liberty of CC'ing the GDB discussion mailing list on this reply; hope
> that's okay.
>
>> ---------- Forwarded message ----------
>> Date: Sat, 30 Jun 2001 17:44:03 +0200
>> From:
>> To: Benjamin Kosnik <bkoz@redhat.com>
>> Cc: libstdc++@gcc.gnu.org
>> Subject: Re: RFC c++ debugging thread
>>
>> On Fri, Jun 29, 2001 at 12:00:34PM -0700, Benjamin Kosnik wrote:
>> >
>> > Hey C++ people. The gdb folks are doing inventory on C++ support in
>> > the debugger. People who use gdb with C++ should probably scope this
>> > thread and add constructive comments:
>> >
>> > http://sources.redhat.com/ml/gdb/2001-06/msg00219.html
>> >
>> > -benjamin
>>
>> If you can pass this on:
>>
>> 1) When typing expressions that have a scope, it is extremely annoying
>> that the current scope is often not known to gdb - especially the lack
>> of namespace support is annoying. I am using anonymous namespaces
>> frequently and that makes it impossible to set break-points other
>> than by line number.
>> I think that when gdb is in a function 'A::(unamed)::C::f()', and I
>> ask for 'g()', it should use the same lookup as the compiler: "(gdb)
>> b g" should set a break point in the same function as that is called
>> when I'd have had: "void A::(unnamed)::C::f(void) { g(); }". The
>> ideal situation being that using an expression that appears after a
>> 'list' command of the current scope will resolve to the correct
>> expression. Another example being that in my current project ALL
>> code that I am debugging is in namespace 'libcw::debug', so why do I
>> constantly have to type: b 'libcw::debug::foo'? I'd like to just
>> type: "(gdb) b foo" (assuming the current code is in scope
>> 'libcw::debug' thus).
>
> Our current understanding is that the namespace lossage is the most
> immediately annoying problem, so that's what we'd like to fix first.
In particular, though, his case is not easy to fix, without reworking gdb's
symbol table, and gcc.
We don't track what the current scope really is, only what the current
function really is (Which isn't necessarily the scope, the scope includes
what is *visible* from that function, which is the part we miss).
On the GCC side, this is because, as I just emailed you, by the time we do
debug output, we don't have using decl's anymore, only their results. And
even then, we have the final view of a namespace (AFAIK, I could be wrong
on this point, but when i just was implementing the namespace support, this
is the distinct feeling i got from looking at what was given to the dwarf2
outputter)
So this one is a little tricky.
>
> We have test cases for some problems, and although your problem sounds
> similar, I can't be sure it's exactly the same problem you are seeing.
> Could you put together a test case, show us what GDB does, and tell us
> what you wish it did? Post to gdb@sources.redhat.com.
>
>> 2) The 'next' command often doesn't work: it just finishes the whole
>> program. I therefore have to use 'step' more often then I like,
>> resulting in entering functions I don't want to enter (like
>> libstdc++/STL stuff). I don't know why/when this happens, but it
>> seems to happen often when returning from a function (on a '}' of a
>> function that I am exiting, I *always* type 's' to avoid losing the
>> trace).
GCC bug.
>> 3) Often wrong source-file:line-numbers are given. This might be a bug
>> in the compiler.
Ditto.
> 4) Not all mangled names are demangled, and obviously
>> the qualifiers are demangled wrongly, assuming you use libiberty's
>> demangler then I suppose this will be fixed. I'll get back to this
>> after my own demangler finally works (I am working on getting adding
>> of substitutions right now).
>
> Again, these sound like something we know about, but I'm not sure. If
> you can provide a test case, that makes it much easier for us to be
> sure we've actually fixed what's bothering you.
Carlo, in number 4, is referring to some weird placement of qualifiers
(const, volatile, etc) in some demangled names.
Nobody has had time to actually fix the demangler yet, since it's purely
cosmetic.
Me, i'm waiting for him to post his demangler source on the libcw cvs, and
i'll do the necessary rewrites in the demangler.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC c++ debugging thread (fwd)
2001-07-02 16:18 ` RFC c++ debugging thread (fwd) Jim Blandy
2001-07-02 16:58 ` Daniel Berlin
@ 2001-07-04 5:15 ` Carlo Wood
2001-07-04 9:26 ` Jim Blandy
1 sibling, 1 reply; 5+ messages in thread
From: Carlo Wood @ 2001-07-04 5:15 UTC (permalink / raw)
To: Jim Blandy; +Cc: gdb
On Mon, Jul 02, 2001 at 06:19:13PM -0500, Jim Blandy wrote:
> We have test cases for some problems, and although your problem sounds
> similar, I can't be sure it's exactly the same problem you are seeing.
> Could you put together a test case, show us what GDB does, and tell us
> what you wish it did? Post to gdb@sources.redhat.com.
Well, this is hard to produce from the top of my head in a small
example program. But I'll try next time I run into it.
Here is one example for a start:
~>cat test.cc
namespace foo {
void g(void)
{
}
void f(void)
{
g();
}
}
int main(void)
{
foo::f();
return 0;
}
~>g++-3.0 -g test.cc
~>gdb a.out
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) b main
Breakpoint 1 at 0x8048626: file test.cc, line 15.
(gdb) r
Starting program: /home/carlo/c++/libcw/src/libcwd/a.out
Breakpoint 1, main () at test.cc:15
15 foo::f();
Current language: auto; currently c++
(gdb) s
foo::f() () at test.cc:9
9 g();
(gdb) b g
Function "g" not defined.
--
Carlo Wood <carlo@alinoe.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC c++ debugging thread (fwd)
2001-07-04 5:15 ` Carlo Wood
@ 2001-07-04 9:26 ` Jim Blandy
2001-07-31 21:31 ` Carlo Wood
0 siblings, 1 reply; 5+ messages in thread
From: Jim Blandy @ 2001-07-04 9:26 UTC (permalink / raw)
To: Carlo Wood; +Cc: gdb
Great --- I've reproduced this. Thanks very much.
This is definitely a case where GCC isn't providing us with the info,
and we're not ready to consume it.
Carlo Wood <carlo@alinoe.com> writes:
>
> On Mon, Jul 02, 2001 at 06:19:13PM -0500, Jim Blandy wrote:
> > We have test cases for some problems, and although your problem sounds
> > similar, I can't be sure it's exactly the same problem you are seeing.
> > Could you put together a test case, show us what GDB does, and tell us
> > what you wish it did? Post to gdb@sources.redhat.com.
>
> Well, this is hard to produce from the top of my head in a small
> example program. But I'll try next time I run into it.
>
> Here is one example for a start:
>
> ~>cat test.cc
> namespace foo {
>
> void g(void)
> {
> }
>
> void f(void)
> {
> g();
> }
> }
>
> int main(void)
> {
> foo::f();
> return 0;
> }
> ~>g++-3.0 -g test.cc
> ~>gdb a.out
> GNU gdb 5.0rh-5 Red Hat Linux 7.1
> Copyright 2001 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-redhat-linux"...
> (gdb) b main
> Breakpoint 1 at 0x8048626: file test.cc, line 15.
> (gdb) r
> Starting program: /home/carlo/c++/libcw/src/libcwd/a.out
>
> Breakpoint 1, main () at test.cc:15
> 15 foo::f();
> Current language: auto; currently c++
> (gdb) s
> foo::f() () at test.cc:9
> 9 g();
> (gdb) b g
> Function "g" not defined.
>
> --
> Carlo Wood <carlo@alinoe.com>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC c++ debugging thread (fwd)
2001-07-04 9:26 ` Jim Blandy
@ 2001-07-31 21:31 ` Carlo Wood
0 siblings, 0 replies; 5+ messages in thread
From: Carlo Wood @ 2001-07-31 21:31 UTC (permalink / raw)
To: Jim Blandy; +Cc: gdb
Hi again...
here's a typical gdb session; I am trying to find a bug (obviously)
and getting VERY frustrated at the moment.
Problem at hand:
~/c++/libcw/src/libcwd/MegaHALv9r1/objs>./MegaHAL++ IRCPlugin.so -n botcrashx -c bottestchan -s diemen.nl.eu.undernet.org
__ __ _ _ _ _ ___
| \/ | ___ __ _ __ _| | | | / \ | | __ __/ _ \
| |\/| |/ _ \/ _` |/ _` | |_| | / _ \ | | \ \ / / (_) |
| | | | __/ (_| | (_| | _ |/ ___ \| |___ \ V / \__, |
|_| |_|\___|\__, |\__,_|_| |_/_/ \_\_____| \_/ /_/r1
|___/
Copyright(C) 1998 Jason Jutchens
Copyright(C) 2000 Orlando Bassotto
-Logo Designed by Daniele Nicolucci-
------------------------------------------------------------
BFD : Calling libcw::debug::dlopen "(nil)".
MALLOC : malloc(13) = <unfinished>
BFD : Warning: Address 0x400073b1 in section .text does not have a line number, perhaps the unit containing the function
`_dl_dst_substitute' wasn't compiled with flag -g
MALLOC : <continued> 0x813f440
MALLOC : calloc(416, 1) = <unfinished>
BFD : Warning: Address 0x4000bcfc in section .text does not have a line number, perhaps the unit containing the function
`_dl_lookup_versioned_symbol_skip' wasn't compiled with flag -g
MALLOC : <continued> 0x8248de0
MALLOC : malloc(25) = <unfinished>
BFD : Warning: Address 0x4000bd0d in section .text does not have a line number, perhaps the unit containing the function
`_dl_lookup_versioned_symbol_skip' wasn't compiled with flag -g
MALLOC : <continued> 0x81ff670
MALLOC : malloc(141) = <unfinished>
BFD : Warning: Address 0x4000be49 in section .text does not have a line number, perhaps the unit containing the function
`_dl_lookup_versioned_symbol_skip' wasn't compiled with flag -g
MALLOC : <continued> 0x81fed80
MALLOC : malloc(212) = <unfinished>
BFD : address 0x4000cfcc corresponds to dl-deps.c:495
MALLOC : <continued> 0x8248f90
MALLOC : calloc(6, 16) = <unfinished>
BFD : address 0x4000ef89 corresponds to dl-version.c:286
MALLOC : <continued> 0x804f280
MALLOC : malloc(84) = <unfinished>
BFD : Warning: Address 0x40366d57 in section .text does not have a line number, perhaps the unit containing the function
`getutmpx' wasn't compiled with flag -g
MALLOC : <continued> 0x8200648
Segmentation fault (core dumped)
Now I start the gdb session:
~/c++/libcw/src/libcwd/MegaHALv9r1/objs>gdb ./MegaHAL++ core
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./MegaHAL++ IRCPlugin.so -n botcrashx -c bottestchan -s diemen.nl.eu.undernet.o'.
Program terminated with signal 11, Segmentation fault.
Error while mapping shared library sections:
libMegaHAL++.so: Success.
Error while mapping shared library sections:
IRCPlugin.so: Success.
Reading symbols from /usr/lib/libreadline.so.4.1...done.
Loaded symbols for /usr/lib/libreadline.so.4.1
Reading symbols from /usr/lib/libncurses.so.5...done.
Loaded symbols for /usr/lib/libncurses.so.5
Reading symbols from libMegaHAL++.so...done.
Loaded symbols for libMegaHAL++.so
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /home/carlo/c++/libcw/src/libcwd/.libs/libcwd.so.0...done.
Loaded symbols for /home/carlo/c++/libcw/src/libcwd/.libs/libcwd.so.0
Reading symbols from /usr/lib/libbfd-2.10.91.0.2.so...done.
Loaded symbols for /usr/lib/libbfd-2.10.91.0.2.so
Reading symbols from /usr/local/gcc-3.0/lib/libstdc++.so.3...done.
Loaded symbols for /usr/local/gcc-3.0/lib/libstdc++.so.3
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/local/gcc-3.0/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/local/gcc-3.0/lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from IRCPlugin.so...done.
Loaded symbols for IRCPlugin.so
#0 0x400ed869 in std::ostream::sentry::sentry(std::ostream&) (this=0xbffff290, __os=@0x10)
at /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc:39
39 : _M_ok(__os.good()), _M_os(__os)
The reason for the core dump is no doubt that __os==@0x10.
Question: Why?
(gdb) up
#1 0x400eefe2 in std::ostream::flush() (this=0x10) at /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc:385
385 sentry __cerb(*this);
(gdb) up
#2 0x400ed8c5 in std::ostream::sentry::sentry(std::ostream&) (this=0xbffff2f8, __os=@0x820a9e0)
at /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc:43
43 __os.tie()->flush();
Apparently tie() returns 0x10. Question: Why?
(gdb) p __os
$1 = (basic_ostream<char,std::char_traits<char> > &) @0x820a9e0: {<basic_ios<char,std::char_traits<char> >> = <invalid address>,
_vptr. = 0x81ffa58}
Well, that didn't help. Lets try stepping to this point.
(gdb) b 43
Breakpoint 1 at 0x400ed8a6: file /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc, line 43.
(gdb) r IRCPlugin.so -n botcrashx -c bottestchan -s diemen.nl.eu.undernet.o
Starting program: /home/carlo/c++/libcw/src/libcwd/MegaHALv9r1/objs/./MegaHAL++ IRCPlugin.so -n botcrashx -c bottestchan -s diemen.nl.eu.undernet.o
Error while mapping shared library sections:
libMegaHAL++.so: Success.
Error in re-setting breakpoint 1:
No source file named /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc.
Error in re-setting breakpoint 1:
No source file named /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc.
Error in re-setting breakpoint 1:
No source file named /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc.
Error in re-setting breakpoint 1:
No source file named /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc.
__ __ _ _ _ _ ___
| \/ | ___ __ _ __ _| | | | / \ | | __ __/ _ \
| |\/| |/ _ \/ _` |/ _` | |_| | / _ \ | | \ \ / / (_) |
| | | | __/ (_| | (_| | _ |/ ___ \| |___ \ V / \__, |
|_| |_|\___|\__, |\__,_|_| |_/_/ \_\_____| \_/ /_/r1
|___/
Copyright(C) 1998 Jason Jutchens
Copyright(C) 2000 Orlando Bassotto
-Logo Designed by Daniele Nicolucci-
------------------------------------------------------------
BFD : Calling libcw::debug::dlopen "(nil)".
MALLOC : malloc(13) = <unfinished>
BFD : Warning: Address 0x400073b1 in section .text does not have a line number, perhaps the unit containing the function
`_dl_dst_substitute' wasn't compiled with flag -g
MALLOC : <continued> 0x81e6dc8
MALLOC : calloc(416, 1) = <unfinished>
BFD : Warning: Address 0x4000bcfc in section .text does not have a line number, perhaps the unit containing the function
`_dl_lookup_versioned_symbol_skip' wasn't compiled with flag -g
MALLOC : <continued> 0x8253e00
MALLOC : malloc(25) = <unfinished>
BFD : Warning: Address 0x4000bd0d in section .text does not have a line number, perhaps the unit containing the function
`_dl_lookup_versioned_symbol_skip' wasn't compiled with flag -g
MALLOC : <continued> 0x81fcee8
MALLOC : malloc(141) = <unfinished>
BFD : Warning: Address 0x4000be49 in section .text does not have a line number, perhaps the unit containing the function
`_dl_lookup_versioned_symbol_skip' wasn't compiled with flag -g
MALLOC : <continued> 0x81fc5f8
MALLOC : malloc(212) = <unfinished>
BFD : address 0x4000cfcc corresponds to dl-deps.c:495
MALLOC : <continued> 0x8253fb0
MALLOC : calloc(6, 16) = <unfinished>
BFD : address 0x4000ef89 corresponds to dl-version.c:286
MALLOC : <continued> 0x804f280
Error while mapping shared library sections:
IRCPlugin.so: Success.
MALLOC : malloc(84) = <unfinished>
BFD : Warning: Address 0x40366d57 in section .text does not have a line number, perhaps the unit containing the function
`getutmpx' wasn't compiled with flag -g
MALLOC : <continued> 0x80508d0
Program received signal SIGSEGV, Segmentation fault.
0x400ed869 in std::ostream::sentry::sentry(std::ostream&) (this=0xbffff270, __os=@0x10)
at /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc:39
39 : _M_ok(__os.good()), _M_os(__os)
Ok, what happened with my breakpoint?
Perhaps I need to do it in steps?
(gdb) d 1
(gdb) b main
Breakpoint 2 at 0x8049c33: file src/MegaHAL++.cpp, line 129.
(gdb) r IRCPlugin.so -n botcrashx -c bottestchan -s diemen.nl.eu.undernet.o
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/carlo/c++/libcw/src/libcwd/MegaHALv9r1/objs/./MegaHAL++ IRCPlugin.so -n botcrashx -c bottestchan -s diemen.nl.eu.undernet.o
Error while mapping shared library sections:
libMegaHAL++.so: Success.
Error in re-setting breakpoint 1:
No source file named /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc.
Error in re-setting breakpoint 1:
No source file named /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc.
Error in re-setting breakpoint 1:
No source file named /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc.
Error in re-setting breakpoint 1:
No source file named /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc.
Breakpoint 2, main (argc=8, argv=0xbffff5bc) at src/MegaHAL++.cpp:129
129 Debug( dc::notice.on() ); // Turn on the NOTICE Debug Channel
(gdb) b ostream.tcc:43
Breakpoint 3 at 0x400ed8a6: file /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc, line 43.
(gdb) c
Continuing.
__ __ _ _ _ _ ___
| \/ | ___ __ _ __ _| | | | / \ | | __ __/ _ \
| |\/| |/ _ \/ _` |/ _` | |_| | / _ \ | | \ \ / / (_) |
| | | | __/ (_| | (_| | _ |/ ___ \| |___ \ V / \__, |
|_| |_|\___|\__, |\__,_|_| |_/_/ \_\_____| \_/ /_/r1
|___/
Copyright(C) 1998 Jason Jutchens
Copyright(C) 2000 Orlando Bassotto
-Logo Designed by Daniele Nicolucci-
------------------------------------------------------------
BFD : Calling libcw::debug::dlopen "(nil)".
MALLOC : malloc(13) = <unfinished>
BFD : Warning: Address 0x400073b1 in section .text does not have a line number, perhaps the unit containing the function
`_dl_dst_substitute' wasn't compiled with flag -g
MALLOC : <continued> 0x81e6dc8
MALLOC : calloc(416, 1) = <unfinished>
BFD : Warning: Address 0x4000bcfc in section .text does not have a line number, perhaps the unit containing the function
`_dl_lookup_versioned_symbol_skip' wasn't compiled with flag -g
MALLOC : <continued> 0x8253e00
MALLOC : malloc(25) = <unfinished>
BFD : Warning: Address 0x4000bd0d in section .text does not have a line number, perhaps the unit containing the function
`_dl_lookup_versioned_symbol_skip' wasn't compiled with flag -g
MALLOC : <continued> 0x81fcee8
MALLOC : malloc(141) = <unfinished>
BFD : Warning: Address 0x4000be49 in section .text does not have a line number, perhaps the unit containing the function
`_dl_lookup_versioned_symbol_skip' wasn't compiled with flag -g
MALLOC : <continued> 0x81fc5f8
MALLOC : malloc(212) = <unfinished>
BFD : address 0x4000cfcc corresponds to dl-deps.c:495
MALLOC : <continued> 0x8253fb0
MALLOC : calloc(6, 16) = <unfinished>
BFD : address 0x4000ef89 corresponds to dl-version.c:286
MALLOC : <continued> 0x804f280
Error while mapping shared library sections:
IRCPlugin.so: Success.
MALLOC : malloc(84) = <unfinished>
BFD : Warning: Address 0x40366d57 in section .text does not have a line number, perhaps the unit containing the function
`getutmpx' wasn't compiled with flag -g
MALLOC : <continued> 0x80508d0
Breakpoint 3, std::ostream::sentry::sentry(std::ostream&) (this=0xbffff2d8, __os=@0x8207fd8)
at /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc:43
43 __os.tie()->flush();
Ok, that worked.
(gdb) p __os
$2 = (basic_ostream<char,std::char_traits<char> > &) @0x8207fd8: {<basic_ios<char,std::char_traits<char> >> = <invalid address>,
_vptr. = 0x81fd2d0}
Still no luck. Not wanting to take any risk, lets use 'si':
(gdb) si
0x400ed8a9 43 __os.tie()->flush();
(gdb)
0x400ed8ac 43 __os.tie()->flush();
(gdb)
0x400ed8ae 43 __os.tie()->flush();
(gdb)
0x400ed8b1 43 __os.tie()->flush();
(gdb)
0x400ed8b3 43 __os.tie()->flush();
(gdb)
0x400ed8b6 43 __os.tie()->flush();
(gdb)
0x400ed8b7 43 __os.tie()->flush();
(gdb)
0x400d16a8 in _init () from /home/carlo/c++/libcw/src/libcwd/.libs/libcwd.so.0
(gdb)
std::basic_ios<char, std::char_traits<char> >::tie() const (this=0xbffff2d8) at /usr/local/gcc-3.0/include/g++-v3/bits/basic_ios.h:145
145 { return _M_tie; }
(gdb) p _M_tie
$3 = (basic_ostream<char,std::char_traits<char> > *) 0x10
(gdb) p *this
$4 = {<ios_base> = {static boolalpha = Cannot access memory at address 0x0
Still no luck getting any overview of this object.
Perhaps when I start a bit higher in the stack frame?
(gdb) bt
#0 std::basic_ios<char, std::char_traits<char> >::tie() const (this=0xbffff2d8) at /usr/local/gcc-3.0/include/g++-v3/bits/basic_ios.h:145
#1 0x400f62f8 in std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char) (__out=@0x8207fd8, __c=40 '(') at /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc:577
#2 0x400d81f0 in libcw::debug::cwbfd::object_file_ct::object_file_ct(char const*, void*) (this=0x81fd2d0,
filename=0xbffff78a "IRCPlugin.so", base=0xffffffff) at bfd.cc:403
#3 0x400dade9 in libcw::debug::dlopen(char const*, int) (name=0xbffff78a "IRCPlugin.so", flags=258) at bfd.cc:1133
#4 0x08049d1c in main (argc=8, argv=0xbffff5bc) at src/MegaHAL++.cpp:151
#5 0x40276f31 in __libc_start_main (main=0x8049c20 <main>, argc=8, ubp_av=0xbffff5bc, init=0x8049528 <_init>, fini=0x804a890 <_fini>,
rtld_fini=0x4000e274 <_dl_fini>, stack_end=0xbffff5b4) at ../sysdeps/generic/libc-start.c:129
(gdb) up
#1 0x400f62f8 in std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char) (__out=@0x8207fd8, __c=40 '(') at /usr/local/gcc-3.0/include/g++-v3/bits/ostream.tcc:577
577 typename __ostream_type::sentry __cerb(__out);
(gdb) p __out
$5 = (basic_ostream<char,std::char_traits<char> > &) @0x8207fd8: {<basic_ios<char,std::char_traits<char> >> = <invalid address>,
_vptr. = 0x81fd2d0}
As expected.
(gdb) up
#2 0x400d81f0 in libcw::debug::cwbfd::object_file_ct::object_file_ct(char const*, void*) (this=0x81fd2d0,
filename=0xbffff78a "IRCPlugin.so", base=0xffffffff) at bfd.cc:403
403 Dout(dc::continued, '(' << hex << lbase << ") ");
Now that sucks, Dout() is a macro that does:
#define DEBUGCHANNELS ::libcw::debug::channels
#define Dout(cntrl, data) LibcwDout(DEBUGCHANNELS, ::libcw::debug::libcw_do, cntrl, data)
#define LibcwDout( dc_namespace, debug_obj, cntrl, data ) \
do \
{ \
DEBUGDEBUGLIBCWDOUTMARKER \
if (debug_obj._off < 0) \
{ \
using namespace ::libcw::debug; \
bool on; \
{ \
using namespace dc_namespace; \
on = (debug_obj|cntrl).on; \
} \
if (on) \
{ \
debug_obj.start(); \
(*debug_obj.current_oss) << data; \
debug_obj.finish(); \
} \
} \
} while(0)
And apparently we are here inside "(*debug_obj.current_oss) << data;".
Lets have a look at the global object 'debug_obj':
(gdb) p '::libcw::debug::libcw_do'
No symbol "::libcw::debug::libcw_do" in current context.
Right
(gdb) p 'libcw::debug::libcw_do'
$6 = {_off = -1, current = 0x8207fd0, current_oss = 0x8207fd8, {channel_set = {<channel_set_data_st> = {label = 0x0, mask = 8192, on = true,
debug_object = 0x40138640}, <No data fields>}, continued_channel_set = {<channel_set_data_st> = {label = 0x0, mask = 8192,
on = true, debug_object = 0x40138640}, <No data fields>}}, orig_os = 0x4022e0c0, os = 0x4022e0c0, start_expected = true,
unfinished_expected = false, laf_stack = {st = {0x8207fd0, 0x0 <repeats 63 times>}, p = 0x40138664, end = 0x40138764}, off_count = 0,
continued_stack = {st = {0 <repeats 64 times>}, p = 0x40138770, end = 0x40138870}, margin = {len = 0, str = 0x4010d588 "",
orig_str = 0x4010d588 "", str_is_allocated = false}, marker = {len = 2, str = 0x4010d486 ": ", orig_str = 0x4010d486 ": ",
str_is_allocated = false}, indent = 0, saved_os = 0x0, interactive = true, initialized = true}
Slightly better. Now there is 'current_oss': 0x8207fd8.
So this must be the problem: current_oss->tie() returns 0x10.
(gdb) p 'libcw::debug::libcw_do'.current_oss
$7 = (basic_ostream<char,std::char_traits<char> > *) 0x8207fd8
(gdb) p *'libcw::debug::libcw_do'.current_oss
virtual baseclass botch
I think I'll have to catch this at the moment it is assigned...
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/carlo/c++/libcw/src/libcwd/MegaHALv9r1/objs/./MegaHAL++ IRCPlugin.so -n botcrashx -c bottestchan -s diemen.nl.eu.undernet.o
Error while mapping shared library sections:
libMegaHAL++.so: Success.
Error in re-setting breakpoint 3:
No source file named ostream.tcc.
Error in re-setting breakpoint 3:
No source file named ostream.tcc.
Error in re-setting breakpoint 3:
No source file named ostream.tcc.
Error in re-setting breakpoint 3:
No source file named ostream.tcc.
Breakpoint 2, main (argc=8, argv=0xbffff5bc) at src/MegaHAL++.cpp:129
129 Debug( dc::notice.on() ); // Turn on the NOTICE Debug Channel
(gdb) d 3
(gdb) watch 'libcw::debug::libcw_do'.current_oss
Hardware watchpoint 4: libcw::debug::libcw_do.current_oss
(gdb) c
Continuing.
__ __ _ _ _ _ ___
| \/ | ___ __ _ __ _| | | | / \ | | __ __/ _ \
| |\/| |/ _ \/ _` |/ _` | |_| | / _ \ | | \ \ / / (_) |
| | | | __/ (_| | (_| | _ |/ ___ \| |___ \ V / \__, |
|_| |_|\___|\__, |\__,_|_| |_/_/ \_\_____| \_/ /_/r1
|___/
Copyright(C) 1998 Jason Jutchens
Copyright(C) 2000 Orlando Bassotto
-Logo Designed by Daniele Nicolucci-
------------------------------------------------------------
Hardware watchpoint 4: libcw::debug::libcw_do.current_oss
Old value = ( *) 0x40138968
New value = ( *) 0x8207fd8
libcw::debug::debug_ct::start() (this=0x40138640) at debug.cc:277
277 if (!(channel_set.mask & (noprefix_cf|nolabel_cf|blank_margin_cf|blank_label_cf|blank_marker_cf)))
(gdb) p 'libcw::debug::libcw_do'.current_oss->_M_tie
Segmentation fault (core dumped)
Great, now gdb core dumped...
Ok, sorry for the long mail :/
I guess this is all related to the same bug/problem. Is it known?
Anything I can do/upgrade to fix it? I am using i686-pc-gnu-linux,
g++-3.0, binutils-2.10.91.0.2...
--
Carlo Wood <carlo@alinoe.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-07-31 21:31 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <Pine.SOL.3.91.1010702120615.3597C-100000@taarna.cygnus.com>
2001-07-02 16:18 ` RFC c++ debugging thread (fwd) Jim Blandy
2001-07-02 16:58 ` Daniel Berlin
2001-07-04 5:15 ` Carlo Wood
2001-07-04 9:26 ` Jim Blandy
2001-07-31 21:31 ` Carlo Wood
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox