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

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

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

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?

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

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 =

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

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

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

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

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