From: Jan Kiszka <jan.kiszka@web.de>
To: george@wildturkeyranch.net
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 15:41:59 +0100 [thread overview]
Message-ID: <47A1DE37.9060202@web.de> (raw)
In-Reply-To: <47A1D9AE.4090206@wildturkeyranch.net>
George Anzinger wrote:
> 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.
Meanwhile I realized that there is early_trap_init - for x86-32 only! I
assume now we are only lacking the same for x86-64 to get kgdb running
there already during early_param-parsing.
Jan
next prev parent reply other threads:[~2008-01-31 14:42 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 ` [Kgdb-bugreport] " George Anzinger
2008-01-31 14:41 ` Jan Kiszka [this message]
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=47A1DE37.9060202@web.de \
--to=jan.kiszka@web.de \
--cc=george@wildturkeyranch.net \
--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
Powered by JetHome