Re: Why GDB always jumps in and jumps out and seems uncontrollable?
Try compiling your program without optimization, and then debugging that. Inlining and instruction scheduling can make it hard to correlate the behavior of the compiled program with that of the source program. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: Visibility into Shared Object files
Are you using the latest release, GDB 5.2? If not, please try that out. If the problem still occurs there, you'll need to give us a specific example of what's going wrong. That is: - a complete test program that we can build and try to debug ourselves, - a transcript showing the GDB behavior you're seeing, and - an (brief) explanation of why the behavior is wrong, if it's not obvious. Stu Rae [EMAIL PROTECTED] writes: I am unable to debug a shared object file using GDB on a Solaris machine using gcc-2.95.2 and the default Solaris 'ld' utility ( Solaris-ELF 4.0) as well as GDB 5.0. I have two shared object files; one is 'C', the other is 'C++' (with extern 'C') I am able to see into the 'C' .so file, but I am not able to see into the 'C++' .so file. I compile both with the '-g' debug option. I load both with the '-Wl,-G' load options. The 'C' code works. The 'C++' does not. Can someone please give me some insight into this problem. I am will to try most anything to get this resolved, I just don't know enough to figure out what to do next. - Thanx Stu ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: numeric_limitsfloat::max
This sounds like a real bug. However, we really can't work on something without a way to reproduce the behavior ourselves. So if you do come up with a small test program, at the very least we'll included it in our test suite, to remind us that the bug is there. Gabriel Zachmann [EMAIL PROTECTED] writes: I have a funny problem with gdb (GNU gdb Red Hat Linux (5.1-1)): In a C++ program I have the following two lines: float v = -numeric_limitsfloat::max(); fprintf(stderr,v=%f\n, v ); When I run the program I always get the output v=-340282346638528859811704183484516925440.00 However, when I run the program in gdb I sometimes get this 375 float v = -numeric_limitsfloat::max(); (gdb) 376 fprintf(stderr,v=%f\n, v ); (gdb) v=nan ^^^ Unfortunately, I seem to be unable to produce a small example program exhibiting this behavior. I compile the program with g++ 3.0.4 using these options: -march=i686 -ansi -fno-default-inline -ffor-scope -g3 -ggdb3 -Wall -W -Wpointer-arith -Wcast-qual -Wcast-align -Wconversion -Woverloaded-virtual -Wsign-compare -Wnon-virtual-dtor -Woverloaded-virtual -Wfloat-equal -Wmissing-prototypes -Wunreachable-code -Wno-reorder -D_GNU_SOURCE Does anybody have any idea what might cause this differing behavior? Thanks a lot in advance, Gabriel. -- /-\ | The mind -- what is it? | | It is the sound of the breeze | | Blowing through the pines in the picture.(Ikkyu)| | | | [EMAIL PROTECTED] __@/' [EMAIL PROTECTED] | | web.informatik.uni-bonn.de/~zach__@/' www.gabrielzachmann.org | \-/ ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: I quit
Rick Crawford [EMAIL PROTECTED] writes: I give up. I can't spend the rest of my half-life fixing other people's bugs. But on the off chance somebody cares about SW quality, Are you volunteering to be a maintainer? If not, how do you think these things get fixed? ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: static variables: no symbol X in current context
[EMAIL PROTECTED] (Michael Hamilton) writes: System: Linux 2.2.16-22 (Redhat 7.?) GDB 5.0 (run inside of xemacs) I don't know if this is a bug or just my problem, but, I haven't been able to figure out how to fix it despite looking at FAQs and docs and websearches. I have a local variable declared static in a subroutine my code. In gdb, when inside the subroutine, I use p x No symbol x in current context. This only seems to happen when running GDB on Linux. When I run it on a solaris/sun machine, it gives me the value. Non-static vars seem to work fine. What am I missing? I'm able to print function-local static variables fine. Can you provide a specific test case we can compile to see the problem on our own systems? ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: Problem reading DWARF 2 .elf from PPC gcc v 2.95.2
Pete Darnell [EMAIL PROTECTED] writes: I get the message Dwarf Error: bad offset (0x1ba37) in compilation unit = header (offset 0x0 + 6) in gdb V5.0 running on a SUN and targeting a = remote PPC running OSE 4.4.=20 Note that the DWARF error happens on the file command before any remote = activity happens. This isn't enough information for us to reproduce the bug. We debug Solaris-x-PPC toolchains all the time. We'd love to fix this. But we need exact, detailed instructions for how to make the bug happen. If we can make the bug occur for us, we can almost certainly fix it; otherwise, we almost certainly cannot. By the way, would the gdb community be interested in a PPC-OSE target? Regards, Sure! ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: Bug in bit fields / gdb large struct/union
Donald Gillies [EMAIL PROTECTED] writes: In gdb (4.18) and with gcc (2.9.5), i cannot change the values of a bit field variable embedded in an elaborate struct/union with the gdb debugger. The debugger gladly accepts it when i try to change the bit field, but i think it's secretly writing the data to the wrong location in memory (see below). This is an ancient version of GDB. You can get a newer one from sources.redhat.com, or from any GNU mirror. ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: gdb futures
Nelson H. F. Beebe [EMAIL PROTECTED] writes: Occasionally in the past, and again this week, I've had occasion to need a facility that no debugger I've ever encountered, including gdb, appears to offer: animation. By that, I mean the ability to run the debugger in a mode where it gets an apparently unbounded stream of next or step instructions which it reads, executes, displays the current statement, and continues. (gdb) zenia:play$ gdb rtti GNU gdb 4.18 Copyright 1998 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) break main Breakpoint 1 at 0x8048716: file rtti.cc, line 33. (gdb) set height 0 (gdb) run Starting program: /home/jimb/c++v3/play/rtti Breakpoint 1, main () at rtti.cc:33 33A a; (gdb) while 1 step end _ZN1AC1Ev (this=0xbfffe050) at rtti.cc:33 33A a; main () at rtti.cc:34 34B b; _ZN1BC1Ev (this=0xbfffe040) at rtti.cc:34 34B b; _ZN1AC2Ev (this=0xbfffe040) at rtti.cc:33 33A a; 0x8048853 in _ZN1BC1Ev (this=0xbfffe040) at rtti.cc:34 34B b; main () at rtti.cc:35 35D d; _ZN1DC1Ev (this=0xbfffe020) at rtti.cc:35 35D d; _ZN1CC2Ev (this=0xbfffe020) at rtti.cc:35 35D d; 0x8048883 in _ZN1DC1Ev (this=0xbfffe020) at rtti.cc:35 35D d; _ZN1AC2Ev (this=0xbfffe028) at rtti.cc:33 33A a; 0x8048892 in _ZN1DC1Ev (this=0xbfffe020) at rtti.cc:35 35D d; main () at rtti.cc:37 ... ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: is_gnu_v3_mangled_dtor
[EMAIL PROTECTED] writes: Trying to build current gdb-cvs with current gcc-3.0 (3.0 20010523) on a linux (2.4.5-p5,glibc 2.2.2) I get gnu-v3-abi.c: In function `init_gnuv3_ops': gnu-v3-abi.c:340: `is_gnu_v3_mangled_dtor' undeclared (first use in this functio Doesn't your tree's `include/demangle.h' file contain a declaration for that function? Mine does; it's at CVS revision 1.8. ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: Seeing #defines in GDB
Jimmy Mc Namara [EMAIL PROTECTED] writes: I have used gdb for a while now but cannot find away of finding out the value of a #define during my debugging( besides jumping out to the header file it is contained in). Is there a method to do this. At the moment, GDB has no information on macro definitions. You can't use macros in expressions, ask if they're defined, etc. The Dwarf 2 debugging format does specify how to encode this information, but GCC doesn't emit it, and GDB wouldn't consume it if it did. ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: feature request
Can the "ignore next N hits of breakpoint" count be reset when you rerun the program with r ? Currently the number is kept, which is confusing when N is too large and a core dump happens before N is reached. Can you describe exactly the behavior that you want? For example, the following sequence of commands should certainly work as expected: (gdb) run ... look around ... decide we want to stop at the 16th hit of breakpoint 2 (gdb) ignore 2 15 (gdb) run I definitely don't think we should just clear all the ignore counts when we run. But perhaps there is some other logic which would make more sense.
