Re: ddb(4) spoils kernel stack in CURRENT?

I've identified the workaround code in DDB. I'll commit a fix as soon as I
have some time to test my changes.

-Kip

On 12/20/06, Kip Macy <kip.macy@xxxxxxxxx> wrote:

I worried that gdb probably had workaround for the large stack argument.
I'll have to dig it up, thanks for the heads up.

-Kip

On 12/20/06, Dmitry Pryanishnikov <dmitry@xxxxxxxxxxxxxx> wrote:
>
>
> Hello!
>
> On Wed, 20 Dec 2006, Kostik Belousov wrote:
> >>> So it looks like a regression in CURRENT vs RELENG_6 (either ddb
> 'spoils'
> >>> the stack somehow, or kgdb fails to unwind it).
> >
> > Could you further localize the problem, i.e. try to backtrace CURRENT
> dump
>
> Good news: I've managed to localize the bug! I'm Feeling Lucky (TM)
> ;)
> just because CURRENT on my notebook was updated approx. at 17-Dec 00:00,
>
> and it didn't manifest such a behaviour! So it was easy to identify the
> regression - it comes with the following commit:
>
> -----------------------------------------------------------------------
>
> Date: Sun, 17 Dec 2006 05:07:01 +0000 (UTC)
> From: Kip Macy <kmacy@xxxxxxxxxxx>
> To: src-committers@xxxxxxxxxxx, cvs-src@xxxxxxxxxxx ,
> cvs-all@xxxxxxxxxxx
> Subject: cvs commit: src/sys/i386/i386 apic_vector.s exception.slocal_apic.c
> trap.c vm86.c vm86bios.s src/sys/i386/include apicvar.h
> src/sys/i386/isa atpic.c atpic_vector.s icu.h
>
> kmacy 2006-12-17 05:07:01 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/i386/i386 apic_vector.s exception.s local_apic.c
> trap.c vm86.c vm86bios.s
> sys/i386/include apicvar.h
> sys/i386/isa atpic.c atpic_vector.s icu.h
> Log:
> Evidently FreeBSD has long relied on the compiler to treat structures
> passed by value (trap frames) as if they were in fact being passed by
>
> reference. For better or worse, this incorrect behaviour is no longer
> present in gcc 4.1. In this patch I convert all trapframe arguments
> to
> be explicitly pass by reference. I also remove vm86_initflags,
> pushing
> the very little work that it actually does up into vm86_prepcall.
>
> -----------------------------------------------------------------------
>
> So kernel built from sources as of date=2006.12.17.05.00.00 gives dump
> with analyzable backtrace, and kernel built from sources as of
> date=2006.12.17.05.10.00 (which include this commit) gives dump
> which confuses kgdb. I believe that commit itself is correct,
> but kgdb contains some workaround against the old (incorrect) behaviour
> of the kernel, so it's the kgdb that should be fixed.
>
> Sincerely, Dmitry
> --
> Atlantis ISP, System Administrator
> e-mail: dmitry@xxxxxxxxxxxxxx
> nic-hdl: LYNX-RIPE
> _______________________________________________
> freebsd-current@xxxxxxxxxxx mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "
> freebsd-current-unsubscribe@xxxxxxxxxxx"
>


_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: ddb(4) spoils kernel stack in CURRENT?
    ... On Wed, 20 Dec 2006, Kostik Belousov wrote: the stack somehow, or kgdb fails to unwind it). ... So it was easy to identify the regression - it comes with the following commit: ... So kernel built from sources as of date=2006.12.17.05.00.00 gives dump ...
    (freebsd-current)
  • Re: ddb(4) spoils kernel stack in CURRENT?
    ... I worried that gdb probably had workaround for the large stack argument. ... or kgdb fails to unwind it). ... Subject: cvs commit: src/sys/i386/i386 apic_vector.s exception.slocal_apic.c ...
    (freebsd-current)
  • Re: New kernel resets immediately
    ... > A kernel built from sources just before the commit by ru@ still ... > that commit is the culprit, otherwise I'll binary search for the broken ... My commit touches boot code only, no kernel i involved, yet things ... So if you're not cdbooting or cdbooting and see the loader prompt, ...
    (freebsd-current)