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.hu...@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 being > > 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 for > > 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 > here: https://docs.rtems.org/branches/master/c-user/symmetric_multiprocessing_services.html#thread-dispatch-details > > > > 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 https://git.rtems.org/rtems/tree/c/src/lib/libbsp/i386/shared/irq/irq_asm.S > I don't know the i386 BSP well and I am not really interested in this > architecture. > > 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 that > > must > > * be saved during an interrupt. This set does not include any which > > 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 + CPU_INTERRUPT_FRAME_SIZE) > > > > 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 to > > the Interrupt_frame? > Yes. > > 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 stack > > pointer is used or how interrupts are dispatched? > On ARM, it is in this file: > https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/arm_exc_interrupt.S > > > >> SMP context switch code (which is incomplete for i386) > > When you say this, does that mean _CPU_Context_switch's bits with "#ifdef > > RTEMS_SMP" > Yes. > > 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' internals - > > 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 myself > > 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.hu...@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.hu...@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.hu...@embedded-brains.de > PGP : Public key available on request. > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
