Piet Delaney wrote:
> On Thu, 2006-10-05 at 17:04 -0700, George Anzinger wrote: 
> 
>>Piet Delaney wrote:
>>
>>>On Thu, 2006-10-05 at 12:17 -0700, Tom Rini wrote:
>>>
>>
>>~
>>
>>
>>>----------------------------------------------------------------------------
>>>
>>>I didn't find the "static init of the trap notify"; 
>>>George: where is that?
>>
>>Have a look here:
>>http://source.mvista.com/~ganzinger/
> 
> 
> I was looking at your 2.4, 2.6.12, and now this 2.6.14-rc1 patch
> and was looking for how you got kgdb to allow setting breakpoints
> as early as the the "FIRST LINE of C CODE".
> 
> Looks like our current kgdb code calls early_trap_init() quite
> late in the boot process:
> 
>     start_kernel_proc() {
>         start_kernel() {
>             setup_arch() {
>                 early_trap_init()
>             }
>         }
>     }
> 
> My guess is that your saying that a developer can add a call to
> breakpoint() in say start_kernel() and it will set up the
> trap table via the calls to set_intr_*:
> 
>     123 void breakpoint(void)
>     124 {
>     125     set_intr_usr_gate(3,&int3); /* disable ints on trap */
>     126     set_intr_gate(1,&debug);
>     127     set_intr_gate(14,&page_fault);
>     128
>     129         BREAKPOINT;
>     130 }
> 
That is correct.  And this depends on the "gate" base being set up by the 
head.c code.  So the call to breakpoint() can be the first C call.

> There's no way to breakpoint the early code without this addition.
> 
> I suppose some arch can't handle traps so early and this is the
> reason early_trap_init() is called from setup_arch().

Different archs will need more or less hardware set up.  The x86 really 
requires very little to get going.  Other will depend on setup_arch()... 
Still all that is needed are the traps for BP, & Sstep (page fault is useful 
but not really needed this early) and an RS232 port.

One would hope that there has not been code added to kgdb that depends on 
anything else...


> 
> 
> There are plenty of other CONFIG #ifdef's in setup_arch():
> 
> #ifdef CONFIG_BLK_DEV_RAM
> #ifdef CONFIG_ACPI_BOOT
> #ifdef CONFIG_ACPI_NUMA
> #ifdef CONFIG_DISCONTIGMEM
> #ifdef CONFIG_SMP 
> #ifdef CONFIG_ACPI_SLEEP
> #ifdef CONFIG_X86_LOCAL_APIC
> #ifdef CONFIG_BLK_DEV_INITRD
> #ifdef CONFIG_ACPI_BOOT
> #ifdef CONFIG_GART_IOMMU
> #ifdef CONFIG_VT
> 
> It appears much more consistent to do the same for the 
> call to  early_trap_init(). Having a few #ifdef's in
> trap.c like we had in the earlier 2.6.*-mm patches is/was
> totally reasonable.
> 
> -piet

-- 
George Anzinger   [EMAIL PROTECTED]


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Kgdb-bugreport mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Reply via email to