Re: [patch 07/15] Basic x86_64 support
On Sun, Aug 07, 2005 at 10:48:02AM +1000, Keith Owens wrote:
> On Thu, 4 Aug 2005 14:39:00 +0200,
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> >> > That doesn't make much sense here. tasklet will only run when interrupts
> >> > are enabled, and that is much later. You could move it to there.
> >>
> >> Where? Keep in mind it's really only x86_64 that isn't able to break
> >> sooner.
> >
> >The local_irq_enable() call in init/main.c:start_kernel()
> >
> >If you want to run gdb earlier you need to do it without a tasklet.
> >
> >> > > --- linux-2.6.13-rc3/include/asm-x86_64/hw_irq.h~x86_64-lite
> >> > > 2005-07-29 13:19:10.0 -0700
> >> > > +++ linux-2.6.13-rc3-trini/include/asm-x86_64/hw_irq.h 2005-07-29
> >> > > 13:19:10.0 -0700
> >> > > @@ -55,6 +55,7 @@ struct hw_interrupt_type;
> >> > > #define TASK_MIGRATION_VECTOR 0xfb
> >> > > #define CALL_FUNCTION_VECTOR 0xfa
> >> > > #define KDB_VECTOR0xf9
> >> > > +#define KGDB_VECTOR 0xf8
> >> >
> >> > I already allocated these vectors for something else.
> >>
> >> Is there another we can use? Just following what looked to be the
> >> logical order.
> >
> >How about you use KDB_VECTOR and rename it to DEBUG_VECTOR
> >and then just check if kgdb is currently active?
> >
> >KDB can do the same.
> >
> >I changed the assignment in my tree like this:
> >
> >#define SPURIOUS_APIC_VECTOR0xff
> >#define ERROR_APIC_VECTOR 0xfe
> >#define RESCHEDULE_VECTOR 0xfd
> >#define CALL_FUNCTION_VECTOR0xfc
> >#define KDB_VECTOR 0xfb/* reserved for KDB */
> >#define THERMAL_APIC_VECTOR 0xfa
> >/* 0xf9 free */
> >#define INVALIDATE_TLB_VECTOR_END 0xf8
> >#define INVALIDATE_TLB_VECTOR_START 0xf0/* f0-f8 used for TLB flush
> >*/
>
> Don't call it {KDB,KGDB,DEBUG}_VECTOR, call it NMI_VECTOR, which is
> what it really is. default_do_nmi() determines if the nmi is due to a
> debugger or some other event. That requires the debuggers to record if
> they are expecting their own nmi, putting all the load on the
> debuggers, where it belongs.
>
> IOW, add NMI_VECTOR to the base code, then add debugger support on top of
> NMI_VECTOR.
Works for me. I'll post something vs 2.6.13-rc6 later today hopefully
that does the rename.
--
Tom Rini
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/15] Basic x86_64 support
On Thu, 4 Aug 2005 14:39:00 +0200,
Andi Kleen <[EMAIL PROTECTED]> wrote:
>> > That doesn't make much sense here. tasklet will only run when interrupts
>> > are enabled, and that is much later. You could move it to there.
>>
>> Where? Keep in mind it's really only x86_64 that isn't able to break
>> sooner.
>
>The local_irq_enable() call in init/main.c:start_kernel()
>
>If you want to run gdb earlier you need to do it without a tasklet.
>
>> > > --- linux-2.6.13-rc3/include/asm-x86_64/hw_irq.h~x86_64-lite
>> > > 2005-07-29 13:19:10.0 -0700
>> > > +++ linux-2.6.13-rc3-trini/include/asm-x86_64/hw_irq.h 2005-07-29
>> > > 13:19:10.0 -0700
>> > > @@ -55,6 +55,7 @@ struct hw_interrupt_type;
>> > > #define TASK_MIGRATION_VECTOR 0xfb
>> > > #define CALL_FUNCTION_VECTOR0xfa
>> > > #define KDB_VECTOR 0xf9
>> > > +#define KGDB_VECTOR 0xf8
>> >
>> > I already allocated these vectors for something else.
>>
>> Is there another we can use? Just following what looked to be the
>> logical order.
>
>How about you use KDB_VECTOR and rename it to DEBUG_VECTOR
>and then just check if kgdb is currently active?
>
>KDB can do the same.
>
>I changed the assignment in my tree like this:
>
>#define SPURIOUS_APIC_VECTOR0xff
>#define ERROR_APIC_VECTOR 0xfe
>#define RESCHEDULE_VECTOR 0xfd
>#define CALL_FUNCTION_VECTOR0xfc
>#define KDB_VECTOR 0xfb/* reserved for KDB */
>#define THERMAL_APIC_VECTOR 0xfa
>/* 0xf9 free */
>#define INVALIDATE_TLB_VECTOR_END 0xf8
>#define INVALIDATE_TLB_VECTOR_START 0xf0/* f0-f8 used for TLB flush */
Don't call it {KDB,KGDB,DEBUG}_VECTOR, call it NMI_VECTOR, which is
what it really is. default_do_nmi() determines if the nmi is due to a
debugger or some other event. That requires the debuggers to record if
they are expecting their own nmi, putting all the load on the
debuggers, where it belongs.
IOW, add NMI_VECTOR to the base code, then add debugger support on top of
NMI_VECTOR.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/15] Basic x86_64 support
On Thu, Aug 04, 2005 at 08:56:32PM +0200, Andi Kleen wrote: > On Thu, Aug 04, 2005 at 08:06:36AM -0700, Tom Rini wrote: > > > > > > Why can't you run on x86-64 early? > > > > As I said earlier: > > " > > > If you want to run gdb earlier you need to do it without a tasklet. > > > > We really would like to try again once stacks are setup (IOW, once > > if ((&__get_cpu_var(init_tss))[0].ist[0])) is true). > > " > > > > IOW, when we parse the params on x86_64 this isn't true (or rather it > > wasn't true as of 2.6.9'ish, if this has changed I'd be glad to retest > > things). > > The ISTs are set up for the boot processor extremly early - even > before start_kernel. But they are useless before trap_init() > runs because you won't get any exceptions that need an IDT (or rather > they will all still point to the early exception handler that just panics) I wonder if there was a reason we couldn't do what we did with i386 and make an early_trap_init() so that we can get what we care about that early at least. I'll have to poke at this a bit more, thanks! -- Tom Rini http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/15] Basic x86_64 support
On Thu, Aug 04, 2005 at 08:06:36AM -0700, Tom Rini wrote: > > > > Why can't you run on x86-64 early? > > As I said earlier: > " > > If you want to run gdb earlier you need to do it without a tasklet. > > We really would like to try again once stacks are setup (IOW, once > if ((&__get_cpu_var(init_tss))[0].ist[0])) is true). > " > > IOW, when we parse the params on x86_64 this isn't true (or rather it > wasn't true as of 2.6.9'ish, if this has changed I'd be glad to retest > things). The ISTs are set up for the boot processor extremly early - even before start_kernel. But they are useless before trap_init() runs because you won't get any exceptions that need an IDT (or rather they will all still point to the early exception handler that just panics) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/15] Basic x86_64 support
On Thu, Aug 04, 2005 at 04:28:06PM +0200, Andi Kleen wrote: > On Thu, Aug 04, 2005 at 07:14:37AM -0700, Tom Rini wrote: > > On Thu, Aug 04, 2005 at 04:06:20PM +0200, Andi Kleen wrote: > > > On Thu, Aug 04, 2005 at 07:04:45AM -0700, Tom Rini wrote: > > > > On Thu, Aug 04, 2005 at 02:39:00PM +0200, Andi Kleen wrote: > > > > > > > That doesn't make much sense here. tasklet will only run when > > > > > > > interrupts > > > > > > > are enabled, and that is much later. You could move it to there. > > > > > > > > > > > > Where? Keep in mind it's really only x86_64 that isn't able to > > > > > > break > > > > > > sooner. > > > > > > > > > > The local_irq_enable() call in init/main.c:start_kernel() > > > > > > > > But as I say, only x86_64 needs this kind of delay. > > > > > > I don't think that's correct. Interrupts should be disabled on all > > > architectures until that. > > > > Right, but we can run sooner elsewhere. It's only x86_64 where we can't > > run when our commandline bits are parsed and need to wait. > > Why can't you run on x86-64 early? As I said earlier: " > If you want to run gdb earlier you need to do it without a tasklet. We really would like to try again once stacks are setup (IOW, once if ((&__get_cpu_var(init_tss))[0].ist[0])) is true). " IOW, when we parse the params on x86_64 this isn't true (or rather it wasn't true as of 2.6.9'ish, if this has changed I'd be glad to retest things). -- Tom Rini http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/15] Basic x86_64 support
On Thu, Aug 04, 2005 at 07:14:37AM -0700, Tom Rini wrote: > On Thu, Aug 04, 2005 at 04:06:20PM +0200, Andi Kleen wrote: > > On Thu, Aug 04, 2005 at 07:04:45AM -0700, Tom Rini wrote: > > > On Thu, Aug 04, 2005 at 02:39:00PM +0200, Andi Kleen wrote: > > > > > > That doesn't make much sense here. tasklet will only run when > > > > > > interrupts > > > > > > are enabled, and that is much later. You could move it to there. > > > > > > > > > > Where? Keep in mind it's really only x86_64 that isn't able to break > > > > > sooner. > > > > > > > > The local_irq_enable() call in init/main.c:start_kernel() > > > > > > But as I say, only x86_64 needs this kind of delay. > > > > I don't think that's correct. Interrupts should be disabled on all > > architectures until that. > > Right, but we can run sooner elsewhere. It's only x86_64 where we can't > run when our commandline bits are parsed and need to wait. Why can't you run on x86-64 early? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/15] Basic x86_64 support
On Thu, Aug 04, 2005 at 04:06:20PM +0200, Andi Kleen wrote: > On Thu, Aug 04, 2005 at 07:04:45AM -0700, Tom Rini wrote: > > On Thu, Aug 04, 2005 at 02:39:00PM +0200, Andi Kleen wrote: > > > > > That doesn't make much sense here. tasklet will only run when > > > > > interrupts > > > > > are enabled, and that is much later. You could move it to there. > > > > > > > > Where? Keep in mind it's really only x86_64 that isn't able to break > > > > sooner. > > > > > > The local_irq_enable() call in init/main.c:start_kernel() > > > > But as I say, only x86_64 needs this kind of delay. > > I don't think that's correct. Interrupts should be disabled on all > architectures until that. Right, but we can run sooner elsewhere. It's only x86_64 where we can't run when our commandline bits are parsed and need to wait. -- Tom Rini http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/15] Basic x86_64 support
On Thu, Aug 04, 2005 at 07:04:45AM -0700, Tom Rini wrote: > On Thu, Aug 04, 2005 at 02:39:00PM +0200, Andi Kleen wrote: > > > > That doesn't make much sense here. tasklet will only run when interrupts > > > > are enabled, and that is much later. You could move it to there. > > > > > > Where? Keep in mind it's really only x86_64 that isn't able to break > > > sooner. > > > > The local_irq_enable() call in init/main.c:start_kernel() > > But as I say, only x86_64 needs this kind of delay. I don't think that's correct. Interrupts should be disabled on all architectures until that. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/15] Basic x86_64 support
On Thu, Aug 04, 2005 at 02:39:00PM +0200, Andi Kleen wrote:
> > > That doesn't make much sense here. tasklet will only run when interrupts
> > > are enabled, and that is much later. You could move it to there.
> >
> > Where? Keep in mind it's really only x86_64 that isn't able to break
> > sooner.
>
> The local_irq_enable() call in init/main.c:start_kernel()
But as I say, only x86_64 needs this kind of delay.
> If you want to run gdb earlier you need to do it without a tasklet.
We really would like to try again once stacks are setup (IOW, once
if ((&__get_cpu_var(init_tss))[0].ist[0])) is true).
> > > > --- linux-2.6.13-rc3/include/asm-x86_64/hw_irq.h~x86_64-lite
> > > > 2005-07-29 13:19:10.0 -0700
> > > > +++ linux-2.6.13-rc3-trini/include/asm-x86_64/hw_irq.h 2005-07-29
> > > > 13:19:10.0 -0700
> > > > @@ -55,6 +55,7 @@ struct hw_interrupt_type;
> > > > #define TASK_MIGRATION_VECTOR 0xfb
> > > > #define CALL_FUNCTION_VECTOR 0xfa
> > > > #define KDB_VECTOR 0xf9
> > > > +#define KGDB_VECTOR0xf8
> > >
> > > I already allocated these vectors for something else.
> >
> > Is there another we can use? Just following what looked to be the
> > logical order.
>
> How about you use KDB_VECTOR and rename it to DEBUG_VECTOR
> and then just check if kgdb is currently active?
I can do the kgdb and generic changes at least.
[snip]
> > > > cfg = __prepare_ICR(shortcut, vector, dest);
> > > > +if (vector == KGDB_VECTOR) {
> > > > + /*
> > > > + * KGDB IPI is to be delivered as a NMI
> > > > + */
> > > > + cfg = (cfg&~APIC_VECTOR_MASK)|APIC_DM_NMI;
> > > > + }
> > >
> > > No way adding another ugly special case like this. I wanted
> > > to rip out the KDB version for a long time.
> >
> > I'd be happy to rework it in a cleaner manner, just point me at an
> > example please.
>
> The code is equivalent to passing shortcut|APIC_DM_NMI and vector == 0
OK. I'll see if I can change things around then, thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/15] Basic x86_64 support
> > That doesn't make much sense here. tasklet will only run when interrupts
> > are enabled, and that is much later. You could move it to there.
>
> Where? Keep in mind it's really only x86_64 that isn't able to break
> sooner.
The local_irq_enable() call in init/main.c:start_kernel()
If you want to run gdb earlier you need to do it without a tasklet.
> > > --- linux-2.6.13-rc3/include/asm-x86_64/hw_irq.h~x86_64-lite
> > > 2005-07-29 13:19:10.0 -0700
> > > +++ linux-2.6.13-rc3-trini/include/asm-x86_64/hw_irq.h2005-07-29
> > > 13:19:10.0 -0700
> > > @@ -55,6 +55,7 @@ struct hw_interrupt_type;
> > > #define TASK_MIGRATION_VECTOR0xfb
> > > #define CALL_FUNCTION_VECTOR 0xfa
> > > #define KDB_VECTOR 0xf9
> > > +#define KGDB_VECTOR 0xf8
> >
> > I already allocated these vectors for something else.
>
> Is there another we can use? Just following what looked to be the
> logical order.
How about you use KDB_VECTOR and rename it to DEBUG_VECTOR
and then just check if kgdb is currently active?
KDB can do the same.
I changed the assignment in my tree like this:
#define SPURIOUS_APIC_VECTOR0xff
#define ERROR_APIC_VECTOR 0xfe
#define RESCHEDULE_VECTOR 0xfd
#define CALL_FUNCTION_VECTOR0xfc
#define KDB_VECTOR 0xfb/* reserved for KDB */
#define THERMAL_APIC_VECTOR 0xfa
/* 0xf9 free */
#define INVALIDATE_TLB_VECTOR_END 0xf8
#define INVALIDATE_TLB_VECTOR_START 0xf0/* f0-f8 used for TLB flush */
but that can be merged later. THere will be probably more changes
with the per CPU IDT planned.
> > > cfg = __prepare_ICR(shortcut, vector, dest);
> > > +if (vector == KGDB_VECTOR) {
> > > + /*
> > > + * KGDB IPI is to be delivered as a NMI
> > > + */
> > > + cfg = (cfg&~APIC_VECTOR_MASK)|APIC_DM_NMI;
> > > + }
> >
> > No way adding another ugly special case like this. I wanted
> > to rip out the KDB version for a long time.
>
> I'd be happy to rework it in a cleaner manner, just point me at an
> example please.
The code is equivalent to passing shortcut|APIC_DM_NMI and vector == 0
> > > - asm volatile(SAVE_CONTEXT
> > > \
> > > + asm volatile(".globl __switch_to_begin\n\t"
> > > \
> > > + "__switch_to_begin:\n\t"
> > > \
> > > + SAVE_CONTEXT
> > > \
> >
> > Why is this needed?
>
> So that backtraces show they're in switch_to rather than somewhere else
> (since it's a #define we wouldn't know otherwise).
Ok.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/15] Basic x86_64 support
On Wed, Aug 03, 2005 at 03:05:31PM +0200, Andi Kleen wrote:
>
> Only reading the changes outside kgdb.c
>
> > +
> > +#ifdef CONFIG_KGDB
> > + /*
> > +* Has KGDB been told to break as soon as possible?
> > +*/
> > + if (kgdb_initialized == -1)
> > + tasklet_schedule(&kgdb_tasklet_breakpoint);
>
> That doesn't make much sense here. tasklet will only run when interrupts
> are enabled, and that is much later. You could move it to there.
Where? Keep in mind it's really only x86_64 that isn't able to break
sooner.
> > diff -puN include/asm-x86_64/hw_irq.h~x86_64-lite
> > include/asm-x86_64/hw_irq.h
> > --- linux-2.6.13-rc3/include/asm-x86_64/hw_irq.h~x86_64-lite
> > 2005-07-29 13:19:10.0 -0700
> > +++ linux-2.6.13-rc3-trini/include/asm-x86_64/hw_irq.h 2005-07-29
> > 13:19:10.0 -0700
> > @@ -55,6 +55,7 @@ struct hw_interrupt_type;
> > #define TASK_MIGRATION_VECTOR 0xfb
> > #define CALL_FUNCTION_VECTOR 0xfa
> > #define KDB_VECTOR 0xf9
> > +#define KGDB_VECTOR0xf8
>
> I already allocated these vectors for something else.
Is there another we can use? Just following what looked to be the
logical order.
> > #define THERMAL_APIC_VECTOR0xf0
> >
> > diff -puN include/asm-x86_64/ipi.h~x86_64-lite include/asm-x86_64/ipi.h
> > --- linux-2.6.13-rc3/include/asm-x86_64/ipi.h~x86_64-lite 2005-07-29
> > 13:19:10.0 -0700
> > +++ linux-2.6.13-rc3-trini/include/asm-x86_64/ipi.h 2005-07-29
> > 13:19:10.0 -0700
> > @@ -62,6 +62,12 @@ static inline void __send_IPI_shortcut(u
> > * No need to touch the target chip field
> > */
> > cfg = __prepare_ICR(shortcut, vector, dest);
> > +if (vector == KGDB_VECTOR) {
> > + /*
> > + * KGDB IPI is to be delivered as a NMI
> > + */
> > + cfg = (cfg&~APIC_VECTOR_MASK)|APIC_DM_NMI;
> > + }
>
> No way adding another ugly special case like this. I wanted
> to rip out the KDB version for a long time.
I'd be happy to rework it in a cleaner manner, just point me at an
example please.
> If anything pass a flag.
In __send_IPI_shortcut? OK.
> > ,"rcx","rbx","rdx","r8","r9","r10","r11","r12","r13","r14","r15"
> >
> > #define switch_to(prev,next,last) \
> > - asm volatile(SAVE_CONTEXT
> > \
> > + asm volatile(".globl __switch_to_begin\n\t"
> > \
> > +"__switch_to_begin:\n\t"
> > \
> > +SAVE_CONTEXT
> > \
>
> Why is this needed?
So that backtraces show they're in switch_to rather than somewhere else
(since it's a #define we wouldn't know otherwise).
--
Tom Rini
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/15] Basic x86_64 support
Only reading the changes outside kgdb.c
> +
> +#ifdef CONFIG_KGDB
> + /*
> + * Has KGDB been told to break as soon as possible?
> + */
> + if (kgdb_initialized == -1)
> + tasklet_schedule(&kgdb_tasklet_breakpoint);
That doesn't make much sense here. tasklet will only run when interrupts
are enabled, and that is much later. You could move it to there.
> diff -puN include/asm-x86_64/hw_irq.h~x86_64-lite include/asm-x86_64/hw_irq.h
> --- linux-2.6.13-rc3/include/asm-x86_64/hw_irq.h~x86_64-lite 2005-07-29
> 13:19:10.0 -0700
> +++ linux-2.6.13-rc3-trini/include/asm-x86_64/hw_irq.h2005-07-29
> 13:19:10.0 -0700
> @@ -55,6 +55,7 @@ struct hw_interrupt_type;
> #define TASK_MIGRATION_VECTOR0xfb
> #define CALL_FUNCTION_VECTOR 0xfa
> #define KDB_VECTOR 0xf9
> +#define KGDB_VECTOR 0xf8
I already allocated these vectors for something else.
> #define THERMAL_APIC_VECTOR 0xf0
>
> diff -puN include/asm-x86_64/ipi.h~x86_64-lite include/asm-x86_64/ipi.h
> --- linux-2.6.13-rc3/include/asm-x86_64/ipi.h~x86_64-lite 2005-07-29
> 13:19:10.0 -0700
> +++ linux-2.6.13-rc3-trini/include/asm-x86_64/ipi.h 2005-07-29
> 13:19:10.0 -0700
> @@ -62,6 +62,12 @@ static inline void __send_IPI_shortcut(u
>* No need to touch the target chip field
>*/
> cfg = __prepare_ICR(shortcut, vector, dest);
> +if (vector == KGDB_VECTOR) {
> + /*
> + * KGDB IPI is to be delivered as a NMI
> + */
> + cfg = (cfg&~APIC_VECTOR_MASK)|APIC_DM_NMI;
> + }
No way adding another ugly special case like this. I wanted
to rip out the KDB version for a long time.
If anything pass a flag.
> ,"rcx","rbx","rdx","r8","r9","r10","r11","r12","r13","r14","r15"
>
> #define switch_to(prev,next,last) \
> - asm volatile(SAVE_CONTEXT
> \
> + asm volatile(".globl __switch_to_begin\n\t"
> \
> + "__switch_to_begin:\n\t"
> \
> + SAVE_CONTEXT
> \
Why is this needed?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 07/15] Basic x86_64 support
CC: Andi Kleen <[EMAIL PROTECTED]>, Amit S Kale <[EMAIL PROTECTED]>
This adds support for the x86_64 architecture. In addition to what was noted
in the core-lite patch about stuff outside of new files, we add -g0 to
compiling of syscalls.o as otherwise we run into problems when debugging
modules, and like i386 annotate switch_to().
---
linux-2.6.13-rc3-trini/arch/x86_64/Kconfig.debug |3
linux-2.6.13-rc3-trini/arch/x86_64/kernel/Makefile |2
linux-2.6.13-rc3-trini/arch/x86_64/kernel/kgdb-jmp.S | 65 ++
linux-2.6.13-rc3-trini/arch/x86_64/kernel/kgdb.c | 462 +++
linux-2.6.13-rc3-trini/arch/x86_64/kernel/traps.c|9
linux-2.6.13-rc3-trini/include/asm-x86_64/hw_irq.h |1
linux-2.6.13-rc3-trini/include/asm-x86_64/ipi.h | 12
linux-2.6.13-rc3-trini/include/asm-x86_64/kgdb.h | 50 ++
linux-2.6.13-rc3-trini/include/asm-x86_64/system.h |6
linux-2.6.13-rc3-trini/lib/Kconfig.debug |2
10 files changed, 607 insertions(+), 5 deletions(-)
diff -puN arch/x86_64/Kconfig.debug~x86_64-lite arch/x86_64/Kconfig.debug
--- linux-2.6.13-rc3/arch/x86_64/Kconfig.debug~x86_64-lite 2005-07-29
13:19:10.0 -0700
+++ linux-2.6.13-rc3-trini/arch/x86_64/Kconfig.debug2005-07-29
13:19:10.0 -0700
@@ -51,7 +51,4 @@ config IOMMU_LEAK
Add a simple leak tracer to the IOMMU code. This is useful when you
are debugging a buggy device driver that leaks IOMMU mappings.
-#config X86_REMOTE_DEBUG
-# bool "kgdb debugging stub"
-
endmenu
diff -puN /dev/null arch/x86_64/kernel/kgdb.c
--- /dev/null 2005-07-25 10:57:32.312383000 -0700
+++ linux-2.6.13-rc3-trini/arch/x86_64/kernel/kgdb.c2005-07-29
13:19:10.0 -0700
@@ -0,0 +1,462 @@
+/*
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+
+/*
+ * Copyright (C) 2004 Amit S. Kale <[EMAIL PROTECTED]>
+ * Copyright (C) 2000-2001 VERITAS Software Corporation.
+ * Copyright (C) 2002 Andi Kleen, SuSE Labs
+ * Copyright (C) 2004 LinSysSoft Technologies Pvt. Ltd.
+ */
+/
+ * Contributor: Lake Stevens Instrument Division$
+ * Written by: Glenn Engel $
+ * Updated by: Amit Kale<[EMAIL PROTECTED]>
+ * Modified for 386 by Jim Kingdon, Cygnus Support.
+ * Origianl kgdb, compatibility with 2.1.xx kernel by
+ * David Grothe <[EMAIL PROTECTED]>
+ * Integrated into 2.2.5 kernel by Tigran Aivazian <[EMAIL PROTECTED]>
+ * X86_64 changes from Andi Kleen's patch merged by Jim Houston
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include /* for linux pt_regs struct */
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Put the error code here just in case the user cares. */
+int gdb_x86_64errcode;
+/* Likewise, the vector number here (since GDB only gets the signal
+ number through the usual means, and that's not very specific). */
+int gdb_x86_64vector = -1;
+
+extern atomic_t cpu_doing_single_step;
+
+void regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *regs)
+{
+ gdb_regs[_RAX] = regs->rax;
+ gdb_regs[_RBX] = regs->rbx;
+ gdb_regs[_RCX] = regs->rcx;
+ gdb_regs[_RDX] = regs->rdx;
+ gdb_regs[_RSI] = regs->rsi;
+ gdb_regs[_RDI] = regs->rdi;
+ gdb_regs[_RBP] = regs->rbp;
+ gdb_regs[_PS] = regs->eflags;
+ gdb_regs[_PC] = regs->rip;
+ gdb_regs[_R8] = regs->r8;
+ gdb_regs[_R9] = regs->r9;
+ gdb_regs[_R10] = regs->r10;
+ gdb_regs[_R11] = regs->r11;
+ gdb_regs[_R12] = regs->r12;
+ gdb_regs[_R13] = regs->r13;
+ gdb_regs[_R14] = regs->r14;
+ gdb_regs[_R15] = regs->r15;
+ gdb_regs[_RSP] = regs->rsp;
+}
+
+extern void thread_return(void);
+void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct
*p)
+{
+ gdb_regs[_RAX] = 0;
+ gdb_regs[_RBX] = 0;
+ gdb_regs[_RCX] = 0;
+ gdb_regs[_RDX] = 0;
+ gdb_regs[_RSI] = 0;
+ gdb_regs[_RDI] = 0;
+ gdb_regs[_RBP] = *(unsigned long *)p->thread.rsp;
+ gdb_regs[_PS] = *(unsigned long *)(p->thread.rsp + 8);
+ gdb_regs[_PC] = (unsigned long)&thread_return;
+ gdb_regs[_R8] = 0;
+ gdb_regs[_R9] = 0;
+ gdb_regs[_R10] = 0;
+ gdb_regs[_R11] = 0;
+ gdb_regs[_R12] = 0;
+ gdb_regs[_R13] = 0;
+ gdb_regs[_R14] = 0;
+ gdb_regs[_R15] = 0;
+ gdb_regs[_RSP] = p->thread.rsp;
+}
+
+void g
