Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 17 Oct 2002 22:34:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 17 Oct 2002 22:34:56 -0400 Received: from zero.aec.at ([193.170.194.10]:37391 "EHLO zero.aec.at") by vger.kernel.org with ESMTP id ; Thu, 17 Oct 2002 22:34:55 -0400 Date: Fri, 18 Oct 2002 04:40:41 +0200 From: Andi Kleen To: Ulrich Drepper Cc: Andi Kleen , Mark Gross , Ingo Molnar , Alexander Viro , S Vamsikrishna , linux-kernel@vger.kernel.org, NPT library mailing list Subject: Re: [patch] thread-aware coredumps, 2.5.43-C3 Message-ID: <20021018024041.GA4015@averell> References: <200210081627.g98GRZP18285@unix-os.sc.intel.com> <200210171835.21647.markgross@thegnar.org> <20021018021242.GA15853@averell> <3DAF70B5.5010208@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DAF70B5.5010208@redhat.com> User-Agent: Mutt/1.4i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2092 Lines: 49 > > I want the x86 CPU error code, which often has interesting clues on > > the problem. > > trapno would be useful too. I suspect other CPUs have similar extended > > state for exceptions. > > > I don't know whether you refer to this but the si_erno and si_code field > of the elf_siginfo structure are currently not used. They are filled > with zero all the time. Could be used yes. > > Eventually (in a future kernel) I would love to have the exception > > handler save the last branch debugging registers of the CPU and the > > let the > > core dumper put that into the dump too. Then you could easily > > figure out what the program did shortly before the crash. > > > One the 2.7 kernel development opens I hope *a lot* will change in the > core dump handling. The current format isn't even adequate to represent > the currently represented information correctly (uid and gid are 16 > bits) and there is other information which isn't even available. You can always extend it with more elf notes. > > I'm perfectly willing to consult anybody who wants to do some work in > this area. Actually, the kernel side should be mostly simple, it "just" > means accessing and copying the right data. At least the debugging register access is not that simple. The exception handler has to be changed into an interrupt gate (to avoid interrupts messing up the state) and then the debugging msrs have to be saved before doing any other jumps. Worse they are CPU specific (P6, P4, and Athlon have it different MSRs. You probably don't want that overhead for normal page faults (reading MSRs is quite costly), so it would need special entry points and could be only done for GPF etc. not for normal segfault. Still I think it would be worth it. More state that could be saved are all the %dr* bits for hardware breakpoint exceptions. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/