From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Daniel Berlin Cc: David Dill , Subject: Re: I can't stand it any more. Date: Sat, 27 Jan 2001 19:18:00 -0000 Message-id: References: X-SW-Source: 2001-01/msg00199.html > > That, and the 13 other bugs in the bug > > database, are all unassigned. > > Why are you emailing gdb@sources about redhat gdb bugs? It just occurred to me that you were referring to gdb's bug database. Forgot we had one. Got confused when you said "generic redhat development environment". Let's try both your examples over on this puter: Breakpoint 1, main () at temp.cc:4 4 cout <<1< = {<_ios_fields> = {_strbuf = 0x17dea78, _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000', _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr.ios = 0x0}, _vb.3ios = 0x1810924} (gdb) p cout << "A string" $2 = (ostream &) @0x1810920: { = {<_ios_fields> = {_strbuf = 0x17dea78, _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000', _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr.ios = 0x0}, _vb.3ios = 0x1810924} (gdb) p endl(cout) 1A string $3 = (ostream &) @0x1810920: { = {<_ios_fields> = {_strbuf = 0x17dea78, _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000', _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr.ios = 0x0}, _vb.ios = 0x1810924} (gdb) Looks fine from here. Of course, this is a ppc. Let's try an x86 : GNU gdb 5.0 Copyright 2000 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 "i686-pc-linux"... (gdb) p cout << 1 $1 = 0 (gdb) p cout << "A string" evaluation of this expression requires the target program to be active (gdb) b main Breakpoint 1 at 0x8048672: file temp.cc, line 4. (gdb) r Starting program: /home/dberlin/./a.out Breakpoint 1, main () at temp.cc:4 4 cout <<1< = {<_ios_fields> = {_strbuf = 0x40065760, _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000', _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. = 0x0}, _vb.ios = 0x8049834} (gdb) p cout << "A string" $3 = (ostream &) @0x8049830: { = {<_ios_fields> = {_strbuf = 0x40065760, _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000', _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. = 0x0}, _vb.ios = 0x8049834} (gdb) p endl(cout) 132544 $4 = (ostream &) @0x8049830: { = {<_ios_fields> = {_strbuf = 0x40065760, _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000', _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. = 0x0}, _vb.ios = 0x8049834} (gdb) Hmmm. Looks like we didn't push the pointer right or something. But the 1 is valid. (gdb) p endl(cout) 32560 $8 = (ostream &) @0x8049830: { = {<_ios_fields> = {_strbuf = 0x40065760, _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000', _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. = 0x0}, _vb.ios = 0x8049834} (gdb) p endl(cout) $9 = (ostream &) @0x8049830: { = {<_ios_fields> = {_strbuf = 0x40065760, _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000', _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. = 0x0}, _vb.ios = 0x8049834} (gdb) p cout << "a" $10 = (ostream &) @0x8049830: { = {<_ios_fields> = {_strbuf = 0x40065760, _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000', _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. = 0x0}, _vb.ios = 0x8049834} (gdb) p endl(cout) 32568 $11 = (ostream &) @0x8049830: { = {<_ios_fields> = {_strbuf = 0x40065760, _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000', _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. = 0x0}, _vb.ios = 0x8049834} (gdb) Monotonically increasing by 8 bytes (I did it a few more times). Sure looks like we aren't pushing the right thing. But it certainly didn't give the error you report. So i don't know what to tell you. > > > > > The current crappy development environment must be very harmful for > > the cause of those trying to develop free software for linux. I know > > it's holding us back. Oh, and a lot of developers Linux has gained are used to examine only debuggers, and thus, don't notice when things are broken like calling virtual functions, becaues they don't call functions. What is holding you back is the fact that those in the cause of those trying to develop free software don't seem to want to help develop gdb at all when it comes to C++ support. I invite you to actually do something about the "current crappy development environment", by helping out. I'd be more than glad for some help. I certainly can't do it all alone. > > HTH, > Dan > > > > David Dill > > > >