[GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Joel Sherrill]

On Tue, Jul 31, 2018 at 3:05 PM, Amaan Cheval <amaan.cheval at gmail.com>
wrote:

> Hm, I'm not sure what to look for in the other ports specifically, really.
> The BSP porting documentation doesn't have a section on interrupts, so I'm
> doing this on more of an "as it comes up" basis.
>
> What I've got right now (the interrupt handlers in C) are what I need for
> calibrating the APIC timer (through the PIT) - so simply hooking IRQ0 (for
> the timer) and IRQ7 (spurious vector), since those are needed for the timer
> work to continue.
>
> What constitutes as a requirement for basic interrupt support?
>

There used to be a generic porting guide. I can see that this particular
section
has bit rotted some but the interrupt dispatching section. Some of this
will have evolved to support SMP and fine grained locking but the
pseudo-code
here will give you a push toward the right line of thinking:

https://docs.rtems.org/releases/rtemsdocs-4.10.2/share/rtems/html/porting/porting00034.html

The idea is that you need to ensure RTEMS knows it is inside an interrupt
and the current locking scheme (old was dispatching, new is ...) is honored.

The ARM and PowerPC (plus RISCV) are good ports to look at for how SMP
plays into this. But the CPU supplement is thin for their interrupt
processing.


This is the CPU Architecture supplement section for the m68k. This is a
relatively simple
architecture to describe. There is also a section for the i386 which reads
similarly.

https://docs.rtems.org/branches/master/cpu-supplement/m68xxx_and_coldfire.html#interrupt-processing

Personally, I find the m68k a fairly easy processor to read assembly in.
Look at cpukit/score/cpu/m68k/cpu_asm.S and _ISR_Handler to see what
is done there w/o SMP. On the m68k _ISR_Handler is directly put into the
vector table. But this isn't the most similar example for you.

For the i386 (better example), it is in bsps/i386/shared/irq/irq_asm.S with
the
same name. There _ISR_Handler is installed via the DISTINCT_INTERRUPT_ENTRY
macros at the bottom of the file where some prologue jumps to the common
_ISR_Handler and then the actions are similar. Usually _ISR_Handler type of
code ends up invoking a PIC decode method in normal C without an
interrupt attribute.

Long and multi-architecture answer but maybe that makes sense. The goal
in ticker.exe is to take a number of tick interrupts which don't schedule
and
then take one that does -- it schedules a preemption of the idle thread.

Hope this helps.

--joel




>
> On Wed, Aug 1, 2018, 1:29 AM Joel Sherrill <joel at rtems.org> wrote:
>
>>
>>
>> On Tue, Jul 31, 2018 at 2:52 PM, Amaan Cheval <amaan.cheval at gmail.com>
>> wrote:
>>
>>> Hi Chris!
>>>
>>> I currently have code like this in c/src/lib/libbsp/x86_64/amd64/
>>> Makefile.am:
>>>
>>>     librtemsbsp_a_SOURCES +=
>>> ../../../../../../bsps/x86_64/amd64/interrupts/handlers.c
>>>     # XXX: Needed to use GCC "interrupt" attribute directives - can we
>>> pass these
>>>     # flags only for the handlers.c source file (compile to an object
>>> file first and
>>>     # then link with the rest for librtemsbsp.a?)
>>>     librtemsbsp_a_CFLAGS = -mgeneral-regs-only
>>>
>>> The CFLAGS arg is required to allow us to use
>>> "__attribute__((interrupt))" to setup interrupt handlers in C. (See
>>> [1] and ctrl+f "interrupt" for more.)
>>>
>>> Is there a way to not force the CFLAGS for _all_ of librtemsbsp, but
>>> to limit it only to handlers.c?
>>>
>>> If not, is the above code something that would be acceptable to have
>>> upstream?
>>>
>>> [1] https://gcc.gnu.org/onlinedocs/gcc/x86-Function-
>>> Attributes.html#x86-Function-Attributes
>>
>>
>> Are we basically talking about the outermost layer of your interrupt
>> dispatching?
>>
>>
>> Have you looked at the basic approach taken by the other ports? They end
>> up switching the stack pointer to a dedicated stack on the outermost
>> interrupt
>> and, if a context switch/dispatch is needed, arrange for the interrupted
>> task to call _Thread_Dispatch.But tinker with its stack so some registers
>> are saved and it looks like it made the call itself.
>>
>> If you can do it in C, I am ok with an attribute. I just don't think you
>> can pull off all the stack and return to dispatch magic that way.
>>
>> --joel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180731/798002a3/attachment-0002.html>