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

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_at_freebsd.org>
To: src-committers_at_freebsd.org, cvs-src_at_freebsd.org, cvs-all_at_freebsd.org
Subject: cvs commit: src/sys/i386/i386 apic_vector.s exception.s local_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_at_atlantis.dp.ua
nic-hdl: LYNX-RIPE