Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262741AbVAQJaK (ORCPT ); Mon, 17 Jan 2005 04:30:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262747AbVAQJaI (ORCPT ); Mon, 17 Jan 2005 04:30:08 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]:65430 "EHLO astro.systems.pipex.net") by vger.kernel.org with ESMTP id S262741AbVAQJ33 (ORCPT ); Mon, 17 Jan 2005 04:29:29 -0500 Date: Mon, 17 Jan 2005 09:30:17 +0000 (GMT) From: Tigran Aivazian X-X-Sender: tigran@ezer.homenet To: "H. Peter Anvin" , Jan Hubicka , Jack F Vogel Cc: linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: [discuss] booting a kernel compiled with -mregparm=0 In-Reply-To: Message-ID: References: <20050114205651.GE17263@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2751 Lines: 54 On Sat, 15 Jan 2005, H. Peter Anvin wrote: > It depends on the architecture ABI. This is the case for the i386 > ABI, but definitely *NOT* for x86-64. Yes, precisely. The ABI/x86_64 defines this behaviour explicitly. However, that would mean the ABI was designed without giving thought to debugging via kdb. When I said "2-3 weeks of work" I didn't fully realize the complexity of the problem. It is actually more like several months of research work and then (most likely) coming to the conclusion that the code to simulate the cpu (by disassembling the functions to track down where those registers went in each function) is just too complex to be written. So, this means there is no way for kdb on x86_64 to show the parameter values for each function in the back trace. Any chance of changing the ABI/x86_64 to do the right (i.e. passing via stack like on i386) thing now? Then kdb would automatically support it via normal ar-handling code. Also, we should NOT claim that Linux has been ported to x86_64 architecture yet, because the port is not clean, i.e. doesn't allow breaking ABI like it allows on i386, by means of CONFIG_REGPARM optimization. Anyone working on fixing this? I cc'd Linus as I cannot believe he agreed with allowing such an optimization to be a default and standard thing accepted by the Linux kernel. (But I may be wrong, especially since Linus isn't particularly fond of kdb anyway :) Actually, having cc'd Linus made me think very _carefully_ about what I say and I went and checked how the userspace does it, as I couldn't believe that such fine piece of software as gdb would be broken as well. And to my surprize I discovered that gdb (when a program is compiled with -g) works fine! I.e. it shows the function arguments correctly. And disassembling the functions shows that although the arguments are passed via registers (as ABI demands) they are also saved somewhere on the stack. Hmmm, interesting, then -g compiled Linux kernel should also be useable, with perhaps some tweaks to kdb to decode these frames correctly, right? I just want someone who knows the answer to confirm the last statement and so then I can go ahead and (try to) implement the solution by mimicking gdb behaviour (or help Jack Vogel implement it if he prefers doing it himself as defacto kdb/x86_64 maintainer) Kind regards Tigran - 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/