From: George Anzinger <george@wildturkeyranch.net>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Jason Wessel <jason.wessel@windriver.com>,
Ingo Molnar <mingo@elte.hu>,
kgdb-bugreport@lists.sourceforge.net,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Kgdb-bugreport] [PATCH 1/5] KGDB: improve early init
Date: Thu, 31 Jan 2008 07:22:38 -0700 [thread overview]
Message-ID: <47A1D9AE.4090206@wildturkeyranch.net> (raw)
In-Reply-To: <47A10355.9090707@web.de>
On 01/31/2008 01:36 AM, Jan Kiszka was caught saying:
> Jan Kiszka wrote:
>> George Anzinger wrote:
>>> On 01/30/2008 04:08 PM, Jan Kiszka was caught saying:
>>>> [Here comes a rebased version against latest x86/mm]
>>>>
>>>> In case "kgdbwait" is passed as kernel parameter, KGDB tries to set up
>>>> and connect to the front-end already during early_param evaluation.
>>>> This
>>>> fails on x86 as the exception stack is not yet initialized,
effectively
>>>> delaying kgdbwait until late-init.
>>>
>>> I wonder how much work it would take to just set up the exception
>>> stack and proceed. After all the kgbdwait is there to help debug
>>> very early kernel code...
>>
>> In principle a valid question, but I'm not the one to answer it. I
>> would not feel very well if I had to reorder this critical setup code.
>> Look, we would have to move trap_init in start_kernel before
>> parse_early_param, and that would affect _every_ arch...
I can not speak to other archs, but for x86 I called trap_init from the
code that caught the kgdbwait. At that time (since I retired, I have
not looked at the actual kernel code) it could be called again later by
the kernel code. I.e. I did not try to reorder the kernel bring up
code, but just added an additional call to trap_init and then only in
the case of finding a kgdbwait.
As such, this would need to be arch specific...
>>
>
> BTW, do you know if EXCEPTION_STACK_READY fails for other archs in
> parse_early_param as well? It should, because my under standing of
> trap_init is that it's the functions to arm things like... exception
> handlers? And that raises the question of the deeper purpose of this
> check (and the invocation of kgdb_early_init from the argument parsing
> function). Sigh, KGDB is still a quite improvable piece of code.
Likely. Once you get it in the main line kernel, one would hope that
other arch code would be forth coming as many more "eyes" will be in play.
>
> Jan
>
> PS: Can we move this to some public list?
Sure, sorry I picked the wrong reply button, never intended it to be
private.
>
--
George Anzinger george@wildturkeyranch.net
next prev parent reply other threads:[~2008-01-31 14:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 23:43 Jan Kiszka
2008-01-30 23:08 ` Jan Kiszka
2008-01-31 14:22 ` George Anzinger [this message]
2008-01-31 14:41 ` [Kgdb-bugreport] " Jan Kiszka
2008-01-31 23:06 ` Jan Kiszka
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=47A1D9AE.4090206@wildturkeyranch.net \
--to=george@wildturkeyranch.net \
--cc=jan.kiszka@web.de \
--cc=jason.wessel@windriver.com \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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®