gdb 6.4 does not stop unwinding even after reaching the last frame.

gdb 6.4 does not stop unwinding even after reaching the last frame.

[Kalpana Ramamurthy]

Hello,

I am using gdb 6.4 for debugging the product that I work on. When I try to 
print a bactrace, I get
an extra frame at the end which looks like this :

#6 0x00000000 in ?? ()

The newer frame (which is frame 5) is supposed to be the last frame. But for 
some reason gdb does
not stop unwinding even after it reaches the last frame and tries to unwind 
further hence hitting
a null backpointer where it cannot unwind any further. The instruction 
pointer is null too.

When I tried using gdb 5.3 to debug the same binary and analyse the same set 
of cores which I had analysed using gdb 6.4, I do not get this extra frame 
problem. The frame unwinding stops
at frame 5. Ther is no null 6th frame.

What is wrong here ? Why the difference in behaviour between gdb 6.4 and gdb 
5.3. I know that gdb 5.3 uses stabs debugging format and gdb 6.4 uses dwarf. 
Could this be a reason for the problem ?

_________________________________________________________________
Palate teasers: Straight from Master Chef Sanjeev Kapoor 
http://content.msn.co.in/Lifestyle/Moreonlifestyle/LifestylePT_101106_1530.htm

Re: gdb 6.4 does not stop unwinding even after reaching the last frame.

[Daniel Jacobowitz]

On Wed, Mar 28, 2007 at 09:23:53AM +0000, Kalpana Ramamurthy wrote:
> Hello,

> I am using gdb 6.4 for debugging the product that I work on. When I try to 
> print a bactrace, I get
> an extra frame at the end which looks like this :

> #6 0x00000000 in ?? ()

There are not a lot of ways to safely indicate the end of the stack.
Due to some internal reorganization, GDB 6.x is usually better about
unwinding through strange things on the stack - but as a consequence
it sometimes unwinds through the last frame too.  Please try a version
from CVS and see if it's any better; it may or may not be.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb 6.4 does not stop unwinding even after reaching the lastframe.

[Kalpana Ramamurthy]

Is there a way to fix this problem in gdb 6.4 itself. I have made a lot of 
code modifications to comply
with my project requirements and it would be difficult to shift to any other 
version of gdb. The code that I am debugging does not have a main() as the 
last function on stack. Instead it has
something else. Can I unwind till it finds that function and then stop 
unwinding ? I see a piece
of code in frame.c for get_prev_frame() function which tests for 
backtrace_past_entry. There is
also a backtrace_limit. Another function iniside_entry_func() seems to check 
if we are inside
the entry function. Can we use all that to determine that the unwinding has 
now reached
the entry level function and it should stop unwinding any further ?


>From: Daniel Jacobowitz <drow@false.org>
>To: Kalpana Ramamurthy <kal_pana@hotmail.com>
>CC: gdb@sourceware.org
>Subject: Re: gdb 6.4 does not stop unwinding even after reaching the 
>lastframe.
>Date: Wed, 28 Mar 2007 07:26:42 -0400
>
>On Wed, Mar 28, 2007 at 09:23:53AM +0000, Kalpana Ramamurthy wrote:
> > Hello,
>
> > I am using gdb 6.4 for debugging the product that I work on. When I try 
>to
> > print a bactrace, I get
> > an extra frame at the end which looks like this :
>
> > #6 0x00000000 in ?? ()
>
>There are not a lot of ways to safely indicate the end of the stack.
>Due to some internal reorganization, GDB 6.x is usually better about
>unwinding through strange things on the stack - but as a consequence
>it sometimes unwinds through the last frame too.  Please try a version
>from CVS and see if it's any better; it may or may not be.
>
>--
>Daniel Jacobowitz
>CodeSourcery

_________________________________________________________________
Spice up your IM conversations. New, colorful and animated emoticons. Get 
chatting! http://server1.msn.co.in/SP05/emoticons/

Re: gdb 6.4 does not stop unwinding even after reaching the lastframe.

[Daniel Jacobowitz]

On Thu, Mar 29, 2007 at 06:36:24AM +0000, Kalpana Ramamurthy wrote:
> the entry function. Can we use all that to determine that the unwinding has now 
> reached
> the entry level function and it should stop unwinding any further ?

Yes, probably.

-- 
Daniel Jacobowitz
CodeSourcery

Errors in gdb6.4 "incomplete CFI data" and "const value length mismatch"

[Kalpana Ramamurthy]

I am using gdb 6.4. I get a lot of errors like

>>During symbol reading, incomplete CFI data; unspecified registers (e.g., 
>>rax) at 0x1452fa.

I also get errors like

>>During symbol reading, const value length mismatch for '<some symbol>', 
>>got 8, expected 0.

From reference to earlier discussions on this issue, I noticed that 
complaints is set to 1 in .gdbinit.
I set it to 0 and these warning messages disappeared.

I had two questions in this regard :

1. Is it a wise thing to set complaints to 0 ?
Setting it to a huge value like "set complaints 20" gives me a huge set of 
the above warnings.

2. Can you let me know the exact cause for why the second warning message 
appears namely
"during symbol reading, const value length...". I assume that the first set 
of warnings related to CFI data is because registers if not specified are 
incorrectly assumed as undefined.

Kalpana
====

_________________________________________________________________
The idiot box is no longer passé; it's making news and how! 
http://content.msn.co.in/Entertainment/TV/Default.aspx

Re: Errors in gdb6.4 "incomplete CFI data" and "const value length mismatch"

[Daniel Jacobowitz]

On Fri, Mar 30, 2007 at 10:47:03AM +0000, Kalpana Ramamurthy wrote:
> I am using gdb 6.4. I get a lot of errors like

> >>During symbol reading, incomplete CFI data; unspecified registers (e.g., rax) 
> >>at 0x1452fa.

> I also get errors like

It's not an error, just a warning.

> >>During symbol reading, const value length mismatch for '<some symbol>', got 
> >>8, expected 0.

I don't know what this one is.

> 1. Is it a wise thing to set complaints to 0 ?
> Setting it to a huge value like "set complaints 20" gives me a huge set of the 
> above warnings.

I think it's perfectly fine - that's why it's the default.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Errors in gdb6.4 "incomplete CFI data" and "const value lengthmismatch"

[Kalpana Ramamurthy]

> > I am using gdb 6.4. I get a lot of errors like
>
> > >>During symbol reading, incomplete CFI data; unspecified registers 
>(e.g., rax)
> > >>at 0x1452fa.
>
> > I also get errors like
>
>It's not an error, just a warning.

Why does it occur and how can  I eliminate this problem ? Setting 
complaints=1 gives me one
instance of this warning. Setting complaints=20 gives me multiple instances 
of it. Maybe by understanding the root cause of this problem, I might be 
able to eliminate the warning completely.

>
> > >>During symbol reading, const value length mismatch for '<some 
>symbol>', got
> > >>8, expected 0.
>
>I don't know what this one is.
>
> > 1. Is it a wise thing to set complaints to 0 ?
> > Setting it to a huge value like "set complaints 20" gives me a huge set 
>of the
> > above warnings.
>
>I think it's perfectly fine - that's why it's the default.
>
>--
>Daniel Jacobowitz
>CodeSourcery

_________________________________________________________________
Catch the complete World Cup coverage with MSN 
http://content.msn.co.in/Sports/Cricket/Default.aspx

Re: Errors in gdb6.4 "incomplete CFI data" and "const value lengthmismatch"

[Daniel Jacobowitz]

On Mon, Apr 02, 2007 at 05:27:43AM +0000, Kalpana Ramamurthy wrote:


> >> I am using gdb 6.4. I get a lot of errors like

> >> >>During symbol reading, incomplete CFI data; unspecified registers (e.g., 
> >rax)
> >> >>at 0x1452fa.

> >> I also get errors like

> >It's not an error, just a warning.

> Why does it occur and how can  I eliminate this problem ? Setting complaints=1 
> gives me one
> instance of this warning. Setting complaints=20 gives me multiple instances of 
> it. Maybe by understanding the root cause of this problem, I might be able to 
> eliminate the warning completely.

Please search the archives for this list and gdb-patches, where it has
been discussed extensively.

-- 
Daniel Jacobowitz
CodeSourcery

Why does gdb print a complete stack trace even after switching to other frames ?

[Kalpana Ramamurthy]

Hello,

Even after switching frames using "frame <frame number>", the backtrace 
prints
a complete backtrace from 0 to the oldest frame. Shouldn't the backtrace be 
from the
switched frame to the oldest frames instead of from the 0'th frame ? For 
example, if I switch to frame 3, bt should print from frame 3 to the oldest 
frame and not from frame 0 to oldest frame.
Why does gdb show this behaviour of printing the complete stack trace 
irrespective of which
frame we are switching on ?

Kalpana
===

_________________________________________________________________
Free & easy posting . Yello Classifieds. 
http://www.yello.in/home.php?utm_source=hotmailtag&utm_medium=textlink&utm_content=in&utm_campaign=april

Re: Why does gdb print a complete stack trace even after switching to other frames ?

[Daniel Jacobowitz]

On Mon, Apr 16, 2007 at 11:26:42AM +0000, Kalpana Ramamurthy wrote:
> Hello,
> 
> Even after switching frames using "frame <frame number>", the backtrace prints
> a complete backtrace from 0 to the oldest frame. Shouldn't the backtrace be 
> from the
> switched frame to the oldest frames instead of from the 0'th frame ?

No, why should it?  Otherwise if you wanted to go down (towards frame
0), you would never know which frame you wanted.

-- 
Daniel Jacobowitz
CodeSourcery

gdb 6.4 not allowing me to change the value of registers like $SP,$RBP and $RIP.

[Kalpana Ramamurthy]

I have a core dump whose registers look like this when I say "info reg" when 
I give this command in gdb 6.4.

(gdb) info reg
rax            0x0      0
rbx            0x9c960a98       2627078808
rcx            0x2      2
rdx            0x0      0
rsi            0x4e1    1249
rdi            0xfee00300       4276093696
rbp            0x9c960a88       0x9c960a88
rsp            0x9c960a50       0x9c960a50
r8             0x1      1
r9             0x3      3
r10            0x0      0
r11            0x216    534
r12            0x9c960be8       2627079144
r13            0x3      3
r14            0x1      1
r15            0x0      0
rip            0x16489d 0x16489d <PANIC+51>
eflags         0x46     70
cs             0x8      8
ss             0x0      0
ds             0x0      0
es             0x0      0
fs             0x0      0
---Type <return> to continue, or q <return> to quit---
gs             0x0      0

I want to change the value of $rsp from 0x9c960a50  to 0x6d04ee0. But gdb is 
not allowing me
to do that. When I say
(gdb) set $sp=0x6d04ee0
or if I say
(gdb) set $rsp=0x6d04ee0
gdb just refuses to change the values and $sp ($rsp) stays on as 0x9c960a50.

I am using gdb 6.4. When I do the same thing as above using gdb 6.0, it 
works great. I am able
to change the values of the registers. Why does this happen only in gdb 6.4 
? I am not able to write macros because of this problem. Please help - where 
am I going wrong ? I have been debugging gdb 6.4 source code for 3 whole 
days now and its driving me nuts. I could see the registers in the regcache 
- and SP shows the new value. From the regcache onwards
I have no idea how gdb translates the contents of the register cache to 
permanent values
where the globals like$rsp etc get set permanently unless we change it back 
again.

Any help will be really appreciated.

Kalpana
====

_________________________________________________________________
Sign in and get updated on all the action from Formula One 
http://content.msn.co.in/Sports/FormulaOne/Default