6:04 a.m.
Hi Dave, Mika, Jan and anyone else interested in the Crash ARM support,
The table based unwind code potentially unwinds the stack pointer to the
existing value of any other register except the PC:
} else if ((insn & 0xf0) == 0x90 &&
(insn & 0x0d) != 0x0d) {
/* 1001 nnnn: set vsp = r[nnnn] */
ctrl->vrs[SP] = ctrl->vrs[insn & 0x0f];
The 'struct stackframe' we use to keep unwind state when going from
one frame to the next (or should I say previous) only contains fp, sp,
lr and pc, which might be something we should consider changing. Even as
it stands however, frame.fp is assigned an incorrect value for active
tasks. Here's a patch to fix that.
diff --git a/unwind_arm.c b/unwind_arm.c
index fd6ac65..6554804 100644
--- a/unwind_arm.c
+++ b/unwind_arm.c
@@ -710,6 +710,7 @@ unwind_backtrace(struct bt_info *bt)
*/
if (bt->machdep) {
const struct arm_pt_regs *regs = bt->machdep;
+ frame.fp = regs->ARM_fp;
frame.lr = regs->ARM_lr;
}
And this time I did remember to run a 'make warn' =o)
Regards,
Per
7:53 a.m.
----- Original Message -----
Hi Dave, Mika, Jan and anyone else interested in the Crash ARM
support,
The table based unwind code potentially unwinds the stack pointer to the
existing value of any other register except the PC:
} else if ((insn & 0xf0) == 0x90 &&
(insn & 0x0d) != 0x0d) {
/* 1001 nnnn: set vsp = r[nnnn] */
ctrl->vrs[SP] = ctrl->vrs[insn & 0x0f];
The 'struct stackframe' we use to keep unwind state when going from
one frame to the next (or should I say previous) only contains fp, sp,
lr and pc, which might be something we should consider changing. Even as
it stands however, frame.fp is assigned an incorrect value for active
tasks. Here's a patch to fix that.
diff --git a/unwind_arm.c b/unwind_arm.c
index fd6ac65..6554804 100644
--- a/unwind_arm.c
+++ b/unwind_arm.c
@@ -710,6 +710,7 @@ unwind_backtrace(struct bt_info *bt)
*/
if (bt->machdep) {
const struct arm_pt_regs *regs = bt->machdep;
+ frame.fp = regs->ARM_fp;
frame.lr = regs->ARM_lr;
}
And this time I did remember to run a 'make warn' =o)
Regards,
Per
I can't comment on the backtrace functionality/query, but the patch
looks reasonable -- although it appears that with the current code,
as is, it would only affect CRASHDEBUG(5) output in unwind_frame()?
Dave
9:57 a.m.
On Thu, Oct 6, 2011 at 2:53 PM, Dave Anderson <anderson(a)redhat.com> wrote:
----- Original Message -----
> Hi Dave, Mika, Jan and anyone else interested in the Crash ARM
> support,
>
> The table based unwind code potentially unwinds the stack pointer to the
> existing value of any other register except the PC:
>
> } else if ((insn & 0xf0) == 0x90 &&
> (insn & 0x0d) != 0x0d) {
> /* 1001 nnnn: set vsp = r[nnnn] */
> ctrl->vrs[SP] = ctrl->vrs[insn & 0x0f];
>
> The 'struct stackframe' we use to keep unwind state when going from
> one frame to the next (or should I say previous) only contains fp, sp,
> lr and pc, which might be something we should consider changing. Even as
> it stands however, frame.fp is assigned an incorrect value for active
> tasks. Here's a patch to fix that.
>
>
> diff --git a/unwind_arm.c b/unwind_arm.c
> index fd6ac65..6554804 100644
> --- a/unwind_arm.c
> +++ b/unwind_arm.c
> @@ -710,6 +710,7 @@ unwind_backtrace(struct bt_info *bt)
> */
> if (bt->machdep) {
> const struct arm_pt_regs *regs = bt->machdep;
> + frame.fp = regs->ARM_fp;
> frame.lr = regs->ARM_lr;
> }
>
>
> And this time I did remember to run a 'make warn' =o)
>
> Regards,
> Per
I can't comment on the backtrace functionality/query, but the patch
looks reasonable -- although it appears that with the current code,
as is, it would only affect CRASHDEBUG(5) output in unwind_frame()?
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
It's used to set ctrl.vrs[FP] in unwind_frame(). A pointer to ctrl is
passed to unwind_exec_insn(), which might use it as the sp for
the preceding frame.
Regards,
Per
12:51 p.m.
On Thu, Oct 06, 2011 at 01:04:07PM +0200, Per Fransson wrote:
The 'struct stackframe' we use to keep unwind state when
going from
one frame to the next (or should I say previous) only contains fp,
sp, lr and pc, which might be something we should consider changing.
Even as it stands however, frame.fp is assigned an incorrect value
for active tasks. Here's a patch to fix that.
I don't understand how it can be incorred - IIRC unwind tables don't use FP at
all. It is only there because that register can be used for other purposes and
some unwinding instructions might restore it from the stack.
Have you seen this problem really happening?
3:07 a.m.
Hi Mika,
On Thu, Oct 6, 2011 at 7:51 PM, Mika Westerberg <mika.westerberg(a)iki.fi> wrote:
On Thu, Oct 06, 2011 at 01:04:07PM +0200, Per Fransson wrote:
> The 'struct stackframe' we use to keep unwind state when going from
> one frame to the next (or should I say previous) only contains fp,
> sp, lr and pc, which might be something we should consider changing.
> Even as it stands however, frame.fp is assigned an incorrect value
> for active tasks. Here's a patch to fix that.
I don't understand how it can be incorred - IIRC unwind tables don't use FP at
all. It is only there because that register can be used for other purposes and
some unwinding instructions might restore it from the stack.
Have you seen this problem really happening?
Indeed I have. Looking up the pc 0xc02c9650 I find this idx entry:
0xc02c9610 0x000376a4
The insn field directs me to the following EHT:
0x81019b42
which contains two instructions:
exec 0x9b : sp = fp
exec 0x42 : sp = sp - 0xc
An uninitialized fp makes this fail. With my oneliner it works.
Regards,
Per
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
8 a.m.
On Fri, Oct 07, 2011 at 10:07:37AM +0200, Per Fransson wrote:
Indeed I have. Looking up the pc 0xc02c9650 I find this idx entry:
0xc02c9610 0x000376a4
The insn field directs me to the following EHT:
0x81019b42
which contains two instructions:
exec 0x9b : sp = fp
exec 0x42 : sp = sp - 0xc
An uninitialized fp makes this fail. With my oneliner it works.
Ok, now I got it :-)
Dave, please include this patch to the next release.
9:59 a.m.
----- Original Message -----
Hi Mika,
On Thu, Oct 6, 2011 at 7:51 PM, Mika Westerberg
<mika.westerberg(a)iki.fi> wrote:
> On Thu, Oct 06, 2011 at 01:04:07PM +0200, Per Fransson wrote:
>
>> The 'struct stackframe' we use to keep unwind state when going from
>> one frame to the next (or should I say previous) only contains fp,
>> sp, lr and pc, which might be something we should consider changing.
>> Even as it stands however, frame.fp is assigned an incorrect value
>> for active tasks. Here's a patch to fix that.
>
> I don't understand how it can be incorred - IIRC unwind tables don't use FP
at
> all. It is only there because that register can be used for other purposes and
> some unwinding instructions might restore it from the stack.
>
> Have you seen this problem really happening?
>
Indeed I have. Looking up the pc 0xc02c9650 I find this idx entry:
0xc02c9610 0x000376a4
The insn field directs me to the following EHT:
0x81019b42
which contains two instructions:
exec 0x9b : sp = fp
exec 0x42 : sp = sp - 0xc
An uninitialized fp makes this fail. With my oneliner it works.
Regards,
Per
Just for the changelog, what does the backtrace failure look like?
Dave
4648
days inactive
4652
days old
devel@lists.crash-utility.osci.io
7 comments
4 participants
participants (4)
-
Dave Anderson -
Mika Westerberg -
Per Fransson -
Per Fransson