RE: View registers from stack frames

RE: View registers from stack frames

[Xinan Tang]

Hi 

  This can be done by issuing these two commands:

  >set debug remote 1
  >set remotelogfile  file_xyz

  Then file_xyz will record everything including the remote protocol
packets.

Good luck

--Xinan

-----Original Message-----
From: gdb-owner@sources.redhat.com [mailto:gdb-owner@sources.redhat.com]
On Behalf Of Fabian Cenedese
Sent: Thursday, October 07, 2004 12:09 AM
To: gdb@sources.redhat.com
Subject: Re: View registers from stack frames

Would it be helpful to have the debug log of the remote protocol
communication? Like that you would see what addresses gdb
probes and the read values. Or maybe a memory dump of the
call stack of a thread?

Thanks

bye  Fabi

Re: View registers from stack frames

[Fabian Cenedese]

>> In frame 0 pc and lr are correct (different), but in the other frames
>> they always have the same value whereas lr should have the
>> value of the pc of the next frame, right?
>
>Recent versions of GDB show the same value for lr and pc for the later
>frames.  I think this is okay.
>
>Kevin

I have only tested the --target=powerpc-eabi version so I don't know about
other processors. Is this true that gdb is supposed to show pc and lr with
the same values for stack frames >0? Isn't the purpose of the lr to point
to the previous stack frame (and so be different from the actual pc)?
And if the actual behaviour is correct then why is it different for frame 0?

Thanks

bye  Fabi

Re: View registers from stack frames

[Kevin Buettner]

On Fri, 08 Oct 2004 10:54:34 +0200
Fabian Cenedese <Cenedese@indel.ch> wrote:

> >> In frame 0 pc and lr are correct (different), but in the other frames
> >> they always have the same value whereas lr should have the
> >> value of the pc of the next frame, right?
> >
> >Recent versions of GDB show the same value for lr and pc for the later
> >frames.  I think this is okay.
> >
> >Kevin
> 
> I have only tested the --target=powerpc-eabi version so I don't know about
> other processors. Is this true that gdb is supposed to show pc and lr with
> the same values for stack frames >0? Isn't the purpose of the lr to point
> to the previous stack frame (and so be different from the actual pc)?
> And if the actual behaviour is correct then why is it different for frame 0?

I agree that this seems counter-intuitive, particularly after working
with it behaving the "other" way for so long.

If you set a breakpoint at the start of a function and the run until that
breakpoint, you'll find that LR does indeed point to the address at which
execution will continue when the current function returns in a normal
manner.  PC will be the address of the instruction at which you've
stopped.  These values should be different.

Now, suppose you step through the function until you reach a call.  If
you step over that call and examine PC and LR, you'll find that they
have the same value.  Why is this so?  It's because the "call" (bl)
instruction puts pc+4 into LR and branches to the function.  Since
you've stepped over the function, and since LR is restored in that
function's prologue, you'll find that LR contains the address at which
you're currently stopped which is in fact the current PC value.

Those lower frames are in the same situation that our top-most frame
is in in the second case.  A "call" was the last instruction to be
executed in that frame; this means that the LR value is actually set to
the value of the PC just after the call.

Looking at it another way, the reason that PC and LR are the same
value for frames other than the topmost frame (excluding possible
sigtramp frames, where they may in fact be different), is because LR
changes over the lifetime of the function.  GDB is reporting this as
accurately as it can.

Kevin

Re: View registers from stack frames

[Fabian Cenedese]

>> I have only tested the --target=powerpc-eabi version so I don't know about
>> other processors. Is this true that gdb is supposed to show pc and lr with
>> the same values for stack frames >0? Isn't the purpose of the lr to point
>> to the previous stack frame (and so be different from the actual pc)?
>> And if the actual behaviour is correct then why is it different for frame 0?
>
>I agree that this seems counter-intuitive, particularly after working
>with it behaving the "other" way for so long.
>
>If you set a breakpoint at the start of a function and the run until that
>breakpoint, you'll find that LR does indeed point to the address at which
>execution will continue when the current function returns in a normal
>manner.  PC will be the address of the instruction at which you've
>stopped.  These values should be different.
>
>Now, suppose you step through the function until you reach a call.  If
>you step over that call and examine PC and LR, you'll find that they
>have the same value.  Why is this so?  It's because the "call" (bl)
>instruction puts pc+4 into LR and branches to the function.  Since
>you've stepped over the function, and since LR is restored in that
>function's prologue, you'll find that LR contains the address at which
>you're currently stopped which is in fact the current PC value.
>
>Those lower frames are in the same situation that our top-most frame
>is in in the second case.  A "call" was the last instruction to be
>executed in that frame; this means that the LR value is actually set to
>the value of the PC just after the call.
>
>Looking at it another way, the reason that PC and LR are the same
>value for frames other than the topmost frame (excluding possible
>sigtramp frames, where they may in fact be different), is because LR
>changes over the lifetime of the function.  GDB is reporting this as
>accurately as it can.

Thanks for your extensive explanation, it looks more clear now why
it is the way it is. The value I assumed to be in LR (PC in last frame)
is still reported from gdb as "saved PC". Is there another possibility
to get this value than the stack frame info? Is this maybe stored in
some gdb internal variable?

Thanks

bye  Fabi

Re: View registers from stack frames

[Kevin Buettner]

On Tue, 12 Oct 2004 08:56:40 +0200
Fabian Cenedese <Cenedese@indel.ch> wrote:

> >Looking at it another way, the reason that PC and LR are the same
> >value for frames other than the topmost frame (excluding possible
> >sigtramp frames, where they may in fact be different), is because LR
> >changes over the lifetime of the function.  GDB is reporting this as
> >accurately as it can.
> 
> Thanks for your extensive explanation, it looks more clear now why
> it is the way it is. The value I assumed to be in LR (PC in last frame)
> is still reported from gdb as "saved PC". Is there another possibility
> to get this value than the stack frame info? Is this maybe stored in
> some gdb internal variable?

From the stack?  If I'm not mistaken, the saved LR value should be at
$sp+4.

I'm not aware of any GDB internal variables which hold this value.

Kevin

View registers from stack frames

[Fabian Cenedese]

Hi

With the stack commands (frame, up, down) I can select a different
stack frame. Local variables and arguments (even with same name)
have different values, depending on the stack frame number. But it
seems that registers aren't corrected for previous stack frames. Is
this correct? e.g. the PC and LR should change their value on every
frame, and the PC was the last LR. But "info reg" always shows the
same values. Is there any way to get the previous frame's registers?

When I do "info frame x" I get something like "saved pc 0x..." so at
least this information is available, why isn't this put into the register
overview? And what about the other SPRs and GPRs?

Thanks

bye  Fabi

Re: View registers from stack frames

[Andrew Cagney]

> Hi
> 
> With the stack commands (frame, up, down) I can select a different
> stack frame. Local variables and arguments (even with same name)
> have different values, depending on the stack frame number. But it
> seems that registers aren't corrected for previous stack frames. Is
> this correct? e.g. the PC and LR should change their value on every
> frame, and the PC was the last LR. But "info reg" always shows the
> same values. Is there any way to get the previous frame's registers?
> 
> When I do "info frame x" I get something like "saved pc 0x..." so at
> least this information is available, why isn't this put into the register
> overview? And what about the other SPRs and GPRs?

You've just described the expected and correct behavior.  That makes it 
sound like an architecture specific bug.  Which architecture system is 
this on, and can you post a transcript.

Andrew

Re: View registers from stack frames

[Fabian Cenedese]

>>With the stack commands (frame, up, down) I can select a different
>>stack frame. Local variables and arguments (even with same name)
>>have different values, depending on the stack frame number. But it
>>seems that registers aren't corrected for previous stack frames. Is
>>this correct? e.g. the PC and LR should change their value on every
>>frame, and the PC was the last LR. But "info reg" always shows the
>>same values. Is there any way to get the previous frame's registers?
>>When I do "info frame x" I get something like "saved pc 0x..." so at
>>least this information is available, why isn't this put into the register
>>overview? And what about the other SPRs and GPRs?
>
>You've just described the expected and correct behavior.  That makes it sound like an architecture specific bug.  Which architecture system is this on, and can you post a transcript.

I'm using a self built gdb-6.1.1 for PPC-targets and cygwin. The
communication with the target is over a stub-server to a PPC-board.

This is some sample session snippet:

(gdb) thread 21
[Switching to thread 21 (Thread 1578452)]#0  CMyWorkerTask::Test (
    this=0x1815d4, str=@0x18d734)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:476
476                             while (uTest2 < 3000001){
(gdb) bt
#0  CMyWorkerTask::Test (this=0x1815d4, str=@0x18d734)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:476
#1  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x18d734)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
#2  0x00060408 in CMyWorkerTask::Action (this=0x1815d4)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:433
#3  0x0008c8a8 in CINOSTask::MainLoop (this=0x1815d4)
    at N:\Temp\SAMCLASS\os\inos\Src\Inos.cpp:823
#4  0x0008c6bc in CINOSTask::CINOSTask (this=0x1815d4,
    aName=0x64646464 "|ù\022", aStackSize=1684300900, aPriority=1684300900,
    aFloatingPoint=1684300900, aTimeSlice=1684300900,
    aInterruptsDisabled=1684300900, apHandler=0x64646464, apObject=0x132fb8)
    at N:\Temp\SAMCLASS\os\inos\Src\Inos.cpp:786
#5  0x32414000 in ?? ()

(gdb) p/x $pc
$1 = 0x6056c
(gdb) p/x $lr
$2 = 0x60564

(gdb) f 1
#1  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x18d734)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
469                             Test(str);
(gdb) info frame 1
Stack frame at 0x18d6b4:
 pc = 0x60564 in CMyWorkerTask::Test(CINOSString &)
    (N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469); saved pc 0x60408
 called by frame at 0x18d6fc, caller of frame at 0x18d66c
 source language c++.
 Arglist at 0x18d6b4, args: this=0x1815d4, str=@0x18d734
 Locals at 0x18d6b4, Previous frame's sp in r1

(gdb) p/x $pc
$3 = 0x6056c
(gdb) p/x $lr
$4 = 0x60564

(gdb) frame 2
#2  0x00060408 in CMyWorkerTask::Action (this=0x1815d4)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:433
433                             Test(str);
(gdb) info frame 2
Stack frame at 0x18d6fc:
 pc = 0x60408 in CMyWorkerTask::Action(void)
    (N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:433); saved pc 0x8c8a8
 called by frame at 0x18d7d4, caller of frame at 0x18d6b4
 source language c++.
 Arglist at 0x18d6fc, args: this=0x1815d4
 Locals at 0x18d6fc, Previous frame's sp in r1

(gdb) p/x $pc
$5 = 0x6056c
(gdb) p/x $lr
$6 = 0x60564

My question is: why do pc and lr (and all other registers) always show the same
value even if I have selected another stack frame? I would have expected that pc
changes to 0x60564 in frame 1 and 0x60408 in frame 2, lr likewise to 0x60408
in frame 1 and 0x8c8a8 in frame 2. Why is this not the case? That's a little bit
misleading. I would like not only to see variables and arguments in previous
frames but also the registers.

Thanks

bye  Fabi

Re: View registers from stack frames

[Daniel Jacobowitz]

On Tue, Oct 05, 2004 at 03:53:22PM +0200, Fabian Cenedese wrote:
> 
> >>With the stack commands (frame, up, down) I can select a different
> >>stack frame. Local variables and arguments (even with same name)
> >>have different values, depending on the stack frame number. But it
> >>seems that registers aren't corrected for previous stack frames. Is
> >>this correct? e.g. the PC and LR should change their value on every
> >>frame, and the PC was the last LR. But "info reg" always shows the
> >>same values. Is there any way to get the previous frame's registers?
> >>When I do "info frame x" I get something like "saved pc 0x..." so at
> >>least this information is available, why isn't this put into the register
> >>overview? And what about the other SPRs and GPRs?
> >
> >You've just described the expected and correct behavior.  That makes it sound like an architecture specific bug.  Which architecture system is this on, and can you post a transcript.
> 
> I'm using a self built gdb-6.1.1 for PPC-targets and cygwin. The
> communication with the target is over a stub-server to a PPC-board.

For PPC, try 6.2 instead.

> My question is: why do pc and lr (and all other registers) always show the same
> value even if I have selected another stack frame? I would have expected that pc
> changes to 0x60564 in frame 1 and 0x60408 in frame 2, lr likewise to 0x60408
> in frame 1 and 0x8c8a8 in frame 2. Why is this not the case? That's a little bit
> misleading. I would like not only to see variables and arguments in previous
> frames but also the registers.

As Andrew already explained, this is what is supposed to happen.  It
did not used to work but was fixed by the new frame architecture.

-- 
Daniel Jacobowitz

Re: View registers from stack frames

[Fabian Cenedese]

>> >>With the stack commands (frame, up, down) I can select a different
>> >>stack frame. Local variables and arguments (even with same name)
>> >>have different values, depending on the stack frame number. But it
>> >>seems that registers aren't corrected for previous stack frames. Is
>> >>this correct? e.g. the PC and LR should change their value on every
>> >>frame, and the PC was the last LR. But "info reg" always shows the
>> >>same values. Is there any way to get the previous frame's registers?
>> >>When I do "info frame x" I get something like "saved pc 0x..." so at
>> >>least this information is available, why isn't this put into the register
>> >>overview? And what about the other SPRs and GPRs?
>> >
>> >You've just described the expected and correct behavior.  That makes it sound like an architecture specific bug.  Which architecture system is this on, and can you post a transcript.
>> 
>> I'm using a self built gdb-6.1.1 for PPC-targets and cygwin. The
>> communication with the target is over a stub-server to a PPC-board.
>
>For PPC, try 6.2 instead.
>
>As Andrew already explained, this is what is supposed to happen.  It
>did not used to work but was fixed by the new frame architecture.

Ok, I will try 6.2 then.

Thanks

bye  Fabi

Re: View registers from stack frames

[Fabian Cenedese]

>>> I'm using a self built gdb-6.1.1 for PPC-targets and cygwin. The
>>> communication with the target is over a stub-server to a PPC-board.
>>
>>For PPC, try 6.2 instead.
>>
>>As Andrew already explained, this is what is supposed to happen.  It
>>did not used to work but was fixed by the new frame architecture.
>
>Ok, I will try 6.2 then.

Hmm, that didn't seem to work better... I should say different.

(gdb) thread 21
[Switching to thread 21 (Thread 1578452)]#0  CMyWorkerTask::Test (
    this=0x1815d4, str=@0x18d734)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:476
476                             while (uTest2 < 3000001){
(gdb) bt
#0  CMyWorkerTask::Test (this=0x1815d4, str=@0x18d734)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:476
#1  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x18d734)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
#2  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x210)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
#3  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x0)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
#4  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x64646464)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
#5  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x32414000)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
Previous frame inner to this frame (corrupt stack?)

(gdb) info frame
Stack level 0, frame at 0x18d6b4:
 pc = 0x6056c in CMyWorkerTask::Test(CINOSString &)
    (N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:476); saved pc 0x60564
 called by frame at 0x18d6fc
 source language c++.
 Arglist at 0x18d66c, args: this=0x1815d4, str=@0x18d734
 Locals at 0x18d66c, Previous frame's sp is 0x18d6b4

(gdb) p/x $pc
$1 = 0x6056c
(gdb) p/x $lr
$2 = 0x60564

(gdb) frame 1
#1  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x18d734)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
469                             Test(str);
(gdb) info frame
Stack level 1, frame at 0x18d6fc:
 pc = 0x60564 in CMyWorkerTask::Test(CINOSString &)
    (N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469); saved pc 0x60564
 called by frame at 0x18d7d4, caller of frame at 0x18d6b4
 source language c++.
 Arglist at 0x18d6b4, args: this=0x1815d4, str=@0x18d734
 Locals at 0x18d6b4, Previous frame's sp is 0x18d6fc

(gdb) p/x $pc
$3 = 0x60564
(gdb) p/x $lr
$4 = 0x60564

(gdb) frame 2
#2  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x210)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
469                             Test(str);
(gdb) info frame
Stack level 2, frame at 0x18d7d4:
 pc = 0x60564 in CMyWorkerTask::Test(CINOSString &)
    (N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469); saved pc 0x60564
 called by frame at 0x18d9b4, caller of frame at 0x18d6fc
 source language c++.
 Arglist at 0x18d6fc, args: this=0x1815d4, str=@0x210
 Locals at 0x18d6fc, Previous frame's sp is 0x18d7d4

(gdb) p/x $pc
$5 = 0x60564
(gdb) p/x $lr
$6 = 0x60564


It is better in so far as the pc did change from frame 0 to frame 1.
But now reading the whole call stack is messed up. Funny though
that only the pc stays the same, other values do change.

That was with exactly the same setup as before. But maybe gdb-6.2
needs different values from the stub...? If I go back to gdb-6.1.1
it works again.

Should I try an even newer gdb then?

Thanks

bye  Fabi

Re: View registers from stack frames

[Andrew Cagney]

> It is better in so far as the pc did change from frame 0 to frame 1.
> But now reading the whole call stack is messed up. Funny though
> that only the pc stays the same, other values do change.

That's a separate bug - the new frame unwind code is running into 
trouble.  I'd check a current gdb (:-/), and if no luck, post more 
details here - KevinB is the PPC maintainer.

> That was with exactly the same setup as before. But maybe gdb-6.2
> needs different values from the stub...? If I go back to gdb-6.1.1
> it works again.
> 
> Should I try an even newer gdb then?

Andrew

Re: View registers from stack frames

[Fabian Cenedese]

>>It is better in so far as the pc did change from frame 0 to frame 1.
>>But now reading the whole call stack is messed up. Funny though
>>that only the pc stays the same, other values do change.
>
>That's a separate bug - the new frame unwind code is running into trouble.  I'd check a current gdb (:-/), and if no luck, post more details here - KevinB is the PPC maintainer.

I just tried with gdb-6.2.1 but it has the same errors in the unwinding.

Here is a bt with gdb-6.2.1 of the halted thread:
GNU gdb 6.2.1
--snip--
This GDB was configured as "--host=i686-pc-cygwin --target=powerpc-eabi"...
(gdb) bt
#0  CMyWorkerTask::Test (this=0x1815d4, str=@0x18d734)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:456
#1  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x18d734)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
#2  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0xa)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
#3  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x0)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
#4  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x64646464)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
#5  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x32414000)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
Previous frame inner to this frame (corrupt stack?)

Here is a bt of the same target with gdb-6.1.1 (last working gdb):
GNU gdb 6.1.1
--snip--
This GDB was configured as "--host=i686-pc-cygwin --target=powerpc-eabi"..
(gdb) bt
#0  CMyWorkerTask::Test (this=0x1815d4, str=@0x18d734)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:456
#1  0x00060564 in CMyWorkerTask::Test (this=0x1815d4, str=@0x18d734)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:469
#2  0x00060408 in CMyWorkerTask::Action (this=0x1815d4)
    at N:\Temp\SAMCLASS\Applicat\Src\Test1.cpp:433
#3  0x0008c8a8 in CINOSTask::MainLoop (this=0x1815d4)
    at N:\Temp\SAMCLASS\os\inos\Src\Inos.cpp:823
#4  0x0008c6bc in CINOSTask::CINOSTask (this=0x1815d4,
    aName=0x64646464 "|ù\022", aStackSize=1684300900, aPriority=1684300900,
    aFloatingPoint=1684300900, aTimeSlice=1684300900,
    aInterruptsDisabled=1684300900, apHandler=0x64646464, apObject=0x132fb8)
    at N:\Temp\SAMCLASS\os\inos\Src\Inos.cpp:786
#5  0x32414000 in ?? ()

(It's possible that frames 4 and 5 have wrong data as the start of
our call stack is maybe not properly initialized. 0x64646464 is
our pattern of uninitialized memory.)

The first two frames seem ok, only frame 3 and more are wrong.
If more info is needed (e.g. the remote debug protocol) I can also
post it here or send to anyone.

Well, that only leaves me with the cvs version...

Thanks

bye  Fabi

Re: View registers from stack frames

[Kevin Buettner]

On Wed, 06 Oct 2004 08:53:31 +0200
Fabian Cenedese <Cenedese@indel.ch> wrote:

> The first two frames seem ok, only frame 3 and more are wrong.
> If more info is needed (e.g. the remote debug protocol) I can also
> post it here or send to anyone.
> 
> Well, that only leaves me with the cvs version...

Give the CVS version a try.  If that fails too, could you send me
a test case?

Thanks,

Kevin

Re: View registers from stack frames

[Fabian Cenedese]

>> The first two frames seem ok, only frame 3 and more are wrong.
>> If more info is needed (e.g. the remote debug protocol) I can also
>> post it here or send to anyone.
>> 
>> Well, that only leaves me with the cvs version...
>
>Give the CVS version a try.  If that fails too, could you send me
>a test case?

The cvs version behaves as 6.2 or 6.2.1. I would love to send you a
test case but I don't know how to. I'm working with an embedded
target and some proprietary software. That's why I tried to create
a memory dump and feed this to gdb so I have something I could
send to someone else. But that didn't work out.

Would it be helpful to have the debug log of the remote protocol
communication? Like that you would see what addresses gdb
probes and the read values. Or maybe a memory dump of the
call stack of a thread?

Thanks

bye  Fabi

Re: View registers from stack frames

[Kevin Buettner]

On Thu, 07 Oct 2004 09:08:49 +0200
Fabian Cenedese <Cenedese@indel.ch> wrote:

> >> The first two frames seem ok, only frame 3 and more are wrong.
> >> If more info is needed (e.g. the remote debug protocol) I can also
> >> post it here or send to anyone.
> >> 
> >> Well, that only leaves me with the cvs version...
> >
> >Give the CVS version a try.  If that fails too, could you send me
> >a test case?
> 
> The cvs version behaves as 6.2 or 6.2.1. I would love to send you a
> test case but I don't know how to. I'm working with an embedded
> target and some proprietary software. That's why I tried to create
> a memory dump and feed this to gdb so I have something I could
> send to someone else. But that didn't work out.
> 
> Would it be helpful to have the debug log of the remote protocol
> communication? Like that you would see what addresses gdb
> probes and the read values. Or maybe a memory dump of the
> call stack of a thread?

Fabian and I communicated privately on this matter.  Fabian determined
that it was some custom stack bounds checking code in the prologue which
was causing problems with backtraces.  We still haven't figured out
why this bounds checking code didn't cause earlier versions of GDB
problems with its backtraces.

Kevin