[PATCH 1/3] i386/smp: Define unused CPU_Interrupt_frame to fix compiler error
amaan.cheval at gmail.com
Mon Mar 12 12:32:52 UTC 2018
Brilliant, thanks a ton! That should keep me occupied for a bit.
I originally sent this patch with the intent of merely ridding the i386
targets of compiler errors, for anyone interested in looking into SMP
issues on the arch.
Do you believe that I should look into fixing i386's incomplete SMP
context-switch support for this patch too, or would that be okay as a
follow-up later, given that it seems like there's more incompleteness
regarding SMP for i386?
On Mon, Mar 12, 2018 at 5:54 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:
> On 12/03/18 13:13, Amaan Cheval wrote:
> > Hey! Thanks for the guidance!
> > I did look at cpu_asm.S, but I don't quite get how Interrupt_frame is
> > used, where by "used" I mean it in the sense that fields within it are
> > being set to the actual register values, the way they are with stm/ltm
> > the Context_Control structure.
> This structure is used as a temporary stack to allow interrupt
> processing during a context switch. You find some information about this
> > The reason I'm looking for ways in which state values are saved into the
> > CPU_Interrupt_frame
> The interrupt exception prologue saves the volatile context of the
> interrupted thread into this structure. I guess this is
> I don't know the i386 BSP well and I am not really interested in this
> > struct is because the comment in
> > ./cpukit/score/cpu/no_cpu/include/rtems/score/cpu.h says:
> > /**
> > * @ingroup Management
> > *
> > * This defines the set of integer and processor state registers
> > must
> > * be saved during an interrupt. This set does not include any
> > are
> > * in @ref Context_Control.
> > */
> > In cpu_asm.S, _CPU_Context_switch has only this bit that's relevant to
> > Interrupt_frame:
> > add sp, r2, #(PER_CPU_INTERRUPT_FRAME_AREA +
> > Which is effectively:
> > sp = GET_SELF_CPU_CONTROL() + Per_CPU_Control.Interrupt_frame +
> > sizeof(CPU_Interrupt_frame)
> > If the stack grows downwards, I guess pushing to the stack would write
> > the Interrupt_frame?
> > I'll continue looking at it now that I know this is
> > the correct place to look; perhaps what I'm missing is just how the
> > pointer is used or how interrupts are dispatched?
> On ARM, it is in this file:
> >> SMP context switch code (which is incomplete for i386)
> > When you say this, does that mean _CPU_Context_switch's bits with
> > RTEMS_SMP"
> > or do you mean another function altogether?
> No, the non-SMP context switch should work fine.
> > Sorry if that's a
> > stupid question; evidently I'm not familiar enough with RTEMS'
> > it's easy to get lost until you find just the right thread to unwind the
> > whole thing. :P
> > P.S. - I'm "amaan" on the #rtems IRC in case you think I've confused
> > and gone down the wrong path, and it'd be quicker to clarify on chat.
> > On Mon, Mar 12, 2018 at 12:18 PM Sebastian Huber <
> > sebastian.huber at embedded-brains.de> wrote:
> >> On 10/03/18 15:11, Amaan Cheval wrote:
> >>> CPU_INTERRUPT_FRAME_SIZE needs to also be set to allow the
> > RTEMS_STATIC_ASSERT
> >>> in percpuasm.c to be fulfilled.
> >> The CPU_Interrupt_frame must properly defined. It must be used by the
> >> SMP context switch code (which is incomplete for i386). Please have a
> >> look at the ARM context switch code as an example:
> >> https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/cpu_asm.S
> >> --
> >> Sebastian Huber, embedded brains GmbH
> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> >> Phone : +49 89 189 47 41-16
> >> Fax : +49 89 189 47 41-09
> >> E-Mail : sebastian.huber at embedded-brains.de
> >> PGP : Public key available on request.
> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> Sebastian Huber, embedded brains GmbH
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.huber at embedded-brains.de
> PGP : Public key available on request.
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel