In-Reply-To: <[email protected]>
On Sun, 6 Aug 2006 16:04:40 +0200, Andi Kleen wrote:
> > And the backtraces I saw ended up at L6:
> >
> > | DWARF2 unwinder stuck at 0xc0100210
> >
> > System.map on i386 SMP says:
> >
> > | c0100210 t L6
>
>
> Yes that's the problem. If you check for <= stext/_stext then the unwinder
> won't catch the L6 (which is above it) and report a "stuck" again
Maybe I'm being dense here, but:
c0100210 t L6
c0100212 t check_x87
c010023a t setup_idt
c0100257 t rp_sidt
c0100264 t ignore_int
c0100298 T stext
c0100298 T _stext
It looks like L6 is before _stext to me.
--
Chuck
>> Yes that's the problem. If you check for <= stext/_stext then the unwinder
>> won't catch the L6 (which is above it) and report a "stuck" again
>
>Maybe I'm being dense here, but:
>
>c0100210 t L6
>c0100212 t check_x87
>c010023a t setup_idt
>c0100257 t rp_sidt
>c0100264 t ignore_int
>c0100298 T stext
>c0100298 T _stext
>
>It looks like L6 is before _stext to me.
So it would seem to me. Nevertheless, in my opinion the proper fix is to annotate the call site
(in head.S) to specify a zero EIP as return address (which denotes the bottom of a frame).
Jan
On Monday 07 August 2006 10:00, Jan Beulich wrote:
> >> Yes that's the problem. If you check for <= stext/_stext then the unwinder
> >> won't catch the L6 (which is above it) and report a "stuck" again
> >
> >Maybe I'm being dense here, but:
> >
> >c0100210 t L6
> >c0100212 t check_x87
> >c010023a t setup_idt
> >c0100257 t rp_sidt
> >c0100264 t ignore_int
> >c0100298 T stext
> >c0100298 T _stext
> >
> >It looks like L6 is before _stext to me.
>
> So it would seem to me. Nevertheless, in my opinion the proper fix is to annotate the call site
> (in head.S) to specify a zero EIP as return address (which denotes the bottom of a frame).
Can you please send a patch to do that?
That seems to be missing in some other places too, e.g. i386 sysenter path, x86-64 kernel_thread,
more?
-Andi
>> So it would seem to me. Nevertheless, in my opinion the proper fix is
to annotate the call site
>> (in head.S) to specify a zero EIP as return address (which denotes
the bottom of a frame).
>
>Can you please send a patch to do that?
>
>That seems to be missing in some other places too, e.g. i386 sysenter
path, x86-64 kernel_thread,
>more?
Attaching both an i386 version (boot/idle thread only, you did
kernel_thread already)
and an x86-64 one (boot/idle and kernel_thread). The i386 sysenter path
is a different
thing, there we have an actual caller (though outside of the kernel),
which I'd like to
continue to reflect/catch through arch_unw_user_mode().
Jan
On Tue, 15 Aug 2006 12:33:59 +0200
"Jan Beulich" <[email protected]> wrote:
> >> So it would seem to me. Nevertheless, in my opinion the proper fix is
> to annotate the call site
> >> (in head.S) to specify a zero EIP as return address (which denotes
> the bottom of a frame).
> >
> >Can you please send a patch to do that?
> >
> >That seems to be missing in some other places too, e.g. i386 sysenter
> path, x86-64 kernel_thread,
> >more?
>
> Attaching both an i386 version (boot/idle thread only, you did
> kernel_thread already)
> and an x86-64 one (boot/idle and kernel_thread). The i386 sysenter path
> is a different
> thing,
Ok added thanks.
Re One open question: Should this added push perhaps be made conditional
upon CONFIG_STACK_UNWIND or CONFIG_UNWIND_INFO?
I don't think that's needed because they are all slow paths.
there we have an actual caller (though outside of the kernel),
> which I'd like to
> continue to reflect/catch through arch_unw_user_mode().
Ok, but does it work now? I thought it didn't.
I've also seen a stuck on the x86-64 sysenter path on x86-64.
-Andi
>> which I'd like to
>> continue to reflect/catch through arch_unw_user_mode().
>
>Ok, but does it work now? I thought it didn't.
>I've also seen a stuck on the x86-64 sysenter path on x86-64.
That's the next thing for me to look into.
Jan