How to add the Idle task to Ada runtime

[Jan Sommer]

Am Samstag, 15. August 2015, 12:14:52 schrieb Joel Sherrill:
> On 08/15/2015 11:09 AM, Jan Sommer wrote:
[...]
> >
> > Now is the question why the runtime only reserves memory for56 bytes and why it is 76 bytes large in rtems?
> > I made a quick grep of the header files, but couldn't find the typedef of pthread_attr_t. Where can I find it?
> >
> 
> The C definition is in newlib. It is in newlib/libc/include/sys/types.h.
> 
> The Ada definition is in gcc/ada/s-osinte-rtems.ads.
> 
> They must match and they likely don't. A review of all *_attr_t would be
> recommended.  My quick reading is that the Ada pthread_attr_t doesn't
> account or guardsize or the SMP affinity support.
> 

I checked the *_attr_t-types and as far as I see there is only a minor update to pthread_rwlockattr_t necessary (but the size stayed the same).
I also added the missing fields to pthread_attr_t in ada, but I don't know how to declare the cpu_set_t in Ada

#ifndef CPU_SETSIZE
#define CPU_SETSIZE 32
#endif

/* word in the cpu set */
typedef __uint32_t cpu_set_word_t;

/* Number of bits per cpu_set_t element */
#define _NCPUBITS  (sizeof(cpu_set_word_t) * 8)

/* Number of words in the cpu_set_t array */
#define _NCPUWORDS   (((CPU_SETSIZE)+((_NCPUBITS)-1))/(_NCPUBITS))

/* Define the cpu set structure */
typedef struct _cpuset {
  cpu_set_word_t __bits[_NCPUWORDS];
} cpu_set_t;

What I have so far is:

   type cpu_set_word_t is new unsigned;

   type cpuset_bits_array is array (0 .. _NCPUWORDS) of aliased cpu_set_word_t;

   type cpu_set_t is record
	__bits : cpuset_bits_array;
  end record;

Question is how can I reference _NCPUWORDS in the ada file?
  
> I had another thought which I don't recall if I posted or not. I vaguely 
> recall
> that the Ada init task is supposed to be the lowest Ada priority and
> preemptible. When elaboration creates an Ada task, that new task
> should preempt the Ada task. I suspect the Ada init task is running through
> the Ada code before the created Ada tasks even get a chance to run and
> register their existence with the run-time.
>
> The Ada run-time wraps the user's Ada task body so it gets a chance to
> do some setup and tear down before and after the user task runs. This
> is similar to how RTEMS has _Thread_Handler which invokes the actual
> user thread body. Anyway, if the Ada run-time wrapper never runs, then
> it is likely missing some bookkeeping.
> 

Yes, I think it works as follows:
Activate_tasks calls Create_Task to create the pthread for the Hello_Task.
Afterwards it would set its state from unactivated to runnable. However, because the internal registers were altered by Create_Task it writes the state to somewhere else in the memory (the missing bookkeeping).
Now after the the main task has finished executing it's "null;" statement Complete_Master is called. Here it iterates through the task list and counts the number of children which are still active, but Hello_Task is still "unactivated", so decides that it is not necessary to wait for any children and terminates the runtime.

I will try in the afternoon to restore the overwritten registers manually in gdb. Then we should now more.

> > Best regards,
> >
> >     Jan
> >
> > Am Sonntag, 2. August 2015, 19:25:40 schrieb Jan Sommer:
> >> Am Samstag, 1. August 2015, 12:48:09 schrieb Joel Sherrill:
> >>> On 08/01/2015 12:39 PM, Jan Sommer wrote:
> >>>> I managed to get most of the Ada examples running for the raspberry pi.
> >>>> However, there seem to be no default idle task.
> >>>> If you have
> >>>>
> >>>> with Text_IO; use Text_IO;
> >>>>
> >>>> procedure Hello is
> >>>>
> >>>>      task Hello_Task;
> >>>>
> >>>>      task body Hello_Task is
> >>>>      begin
> >>>> 	delay 5.0;
> >>>>      end Hello_Task;
> >>>>
> >>>> begin
> >>>> 	[1]
> >>>> 	null;
> >>>> end Hello;
> >>>>
> >>>> The runtime will be terminated after the body of the procedure [1] is executed.
> >>>> I think the usual behaviour for Ada would be that instead an idle task is running while the Hello_Task waits.
> >>>> At least it works like this if I compile the file for my desktop-PC.
> >>>>
> >> [...]
> >>> None of that is going to help. This is Ada run-time specific. So it is
> >>> some behavior that needs to be accounted for.
> >>>
> >>> Ada tasks are pthreads on both Linux and RTEMS. One simple thing
> >>> to do would be to check that the pthread attributes are the same on
> >>> the call to pthread_create. I would expect the run-time to be rigorous
> >>> in setting all attributes explicitly but if they don't, then we might be
> >>> missing the attribute that makes a thread joinable.
> >>>
> >> The thread creation seems to be basically the same on Linux and Rtems.
> >> The thread is created as detached.
> >>
> >>> Otherwise, we need to figure out where this is in the run-time and
> >>> see what is going on.
> >>>
> >> After reading about the threading implementation of gnat here: http://www.iuma.ulpgc.es/users/jmiranda/gnat-rts/node18.htm#task_steps
> >> I looked at the "Complete Master" part. I could find a difference in runtime behaviour in the file  /opt/rtems-4.11-pi/lib/gcc/arm-rtems4.11/4.9.3/adainclude/s-tassta.adb
> >>  From line 1704 - 1746 the master is supposed to count the number of active tasks and afterwards in the loop between l. 1755 - 1777 it is supposed to go to sleep (l. 1775) until the number of active tasks is 0.
> >> In Linux this works properly. In Rtems it exits the loop immediately ( exit when Self_ID.Common.Wait_Count = 0; ) and never goes to sleep.
> >> So it appears to me that counting the active tasks fails (i.e. it counts 0 ) somehow. Unfortunately I wasn't able to go deeper.
> >> Most of the temporary variables are optimized out (according to gdb/ddd). I compiled the toolchain with rsb with --targetcflags and targetcxxflags set to "-O0 -g", but still can't print many variables. Is there another trick to have all these variables accessible as well (performance is not an issue)?
> >>
> >>> Asking for advice on gcc at gcc.gnu.org might be useful at this point.
> >>> Please cc' me if you do that.
> >>>> Could someone point me in the right direction?
> >>>>
> >>>> Cheers,
> >>>>
> >>>>      Jan
> >>>>
> >>>> _______________________________________________
> >>>> users mailing list
> >>>> users at rtems.org
> >>>> http://lists.rtems.org/mailman/listinfo/users
> >>>
> >>>
> >> _______________________________________________
> >> users mailing list
> >> users at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/users
> 
> 
>