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 [PATCH 1/5] KGDB: improve early init 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.