mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tigran Aivazian <tigran@veritas.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Jan Hubicka <jh@suse.cz>,
	Jack F Vogel <jfv@bluesong.net>
Cc: linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>
Subject: Re: [discuss] booting a kernel compiled with -mregparm=0
Date: Mon, 17 Jan 2005 09:30:17 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.61.0501170909040.4593@ezer.homenet> (raw)
In-Reply-To: <cs9v6f$3tj$1@terminus.zytor.com>

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.

<begin stuff superseded by later findings, but left here to clarify the 
train of thoughts>
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 :)
<end of stuff declared as superceded>

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

  reply	other threads:[~2005-01-17  9:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-14 16:34 Tigran Aivazian
2005-01-14 20:56 ` [discuss] " Jan Hubicka
2005-01-14 21:28   ` linux-os
2005-01-15  2:29     ` H. Peter Anvin
2005-01-17  9:30       ` Tigran Aivazian [this message]
2005-01-17  9:53         ` Arjan van de Ven
2005-01-17 10:04           ` Tigran Aivazian
2005-01-17 18:10             ` H. Peter Anvin
2005-01-17 20:22               ` Andi Kleen
2005-01-17 20:38                 ` H. Peter Anvin
2005-01-17 22:08                   ` Andi Kleen
2005-01-18 11:25                   ` Tigran Aivazian
2005-01-18 11:51                     ` Arjan van de Ven
2005-01-18 13:04                     ` Tigran Aivazian
2005-01-18 13:16                       ` Tigran Aivazian
2005-01-17 10:59         ` Andi Kleen
2005-01-17 13:17           ` Tigran Aivazian
2005-01-17 16:38         ` Linus Torvalds
2005-01-18 20:38         ` Keith Owens
2005-01-18 23:15           ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.61.0501170909040.4593@ezer.homenet \
    --to=tigran@veritas.com \
    --cc=hpa@zytor.com \
    --cc=jfv@bluesong.net \
    --cc=jh@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®