gnat 4.9.2 on arm with rtems

2015-10-25 Thread Jan Sommer
Hello,

I try to get the a working gnat toolchain running to build binaries for the 
raspberry pi with rtems4.11.
For debugging purposes the pi is emulated in qemu.

Currently I try to get the following basic tasking example to run:

with Text_IO; use Text_IO;

procedure Hello is

   task Hello_Task;

   task body Hello_Task is
   begin
 Put_Line ("*** GNAT/RTEMS Hello World Test ***");
 New_Line;
 Put_Line ("Welcome to the World of Lady Ada");

 New_Line;
 Put_Line ("Initiating 20 second delay");
 delay 20.0;
 Put_Line ("Delay Complete");

 Put_Line ("*** END OF GNAT/RTEMS Hello World Test ***");
   end Hello_Task;

begin
Put_Line ("Main program");
null;
end Hello;

After rtems initialization a thread is created which calls the gnat_main 
function and then runs the rts and the task.
What I see so far is that after the hello_tasks delays itself the 
Complete_Master procedure (s-tassta.adb:444) is called, but with Self_Id set to 
the Id of the hello_task.
The call finishes and the runtime is cleaned before the task if able to wake up.
If I debug the same program on my desktop pc  Complete_Master is called with 
the Id of the main task. It then notices that it has to wait for its  dependent 
task (hello_task), sleeps until it finishes and  only then terminates the 
runtime.

I would like to know from where Complete_Master is called to break there and 
find out why it uses the wrong id.
Also general tips on how to debug that kind of thing would be greatly 
appreciated.

Thank you very much,

 Jan


Re: gnat 4.9.2 on arm with rtems

2015-10-25 Thread Jan Sommer
Am Sunday 25 October 2015, 18:13:53 schrieb Arnaud Charlet:
> > After rtems initialization a thread is created which calls the gnat_main
> > function and then runs the rts and the task.
> > What I see so far is that after the hello_tasks delays itself the
> > Complete_Master procedure (s-tassta.adb:444) is called, but with
> > Self_Id set to the Id of the hello_task.
> > The call finishes and the runtime is cleaned before the task if able to wake
> > up.
> > If I debug the same program on my desktop pc  Complete_Master is called with
> > the Id of the main task. It then notices that it has to wait for its  
> > dependent
> > task (hello_task), sleeps until it finishes and  only then terminates the
> > runtime.
> > 
> > I would like to know from where Complete_Master is called to break there and
> > find out why it uses the wrong id.
> 
> Why don't you simply put a breakpoint on Complete_Master?
> 

That's how I found out about the wrong/weird Self_Id.

> You can also build hello.adb with the -gnatD switch to debug at the code
> expansion level where you'll see the call to Complete_Master.
> 

Thank you, that option helps a lot. Will check out the generated code tomorrow.

Jan.



Re: gnat 4.9.2 on arm with rtems

2015-10-26 Thread Jan Sommer
Am Monday 26 October 2015, 08:26:57 schrieb Joel Sherrill:
> Hi
> 
> I am on travel this week but I thought we had this problem
> solved. I poked on a build server I used but can't find
> the change and it doesn't look to be committed.
> 

Yes, it was me back then too ;-)
I have been occupied the last months.

> The issue was that the contents of read_attr_t has changed
> and the Ada definition of the same structure needs to be
> updated. This is defined in pthread.h in newlib or an
> installed tools. The Ada version is in
> gcc/ada/s-osinte-rtems.ads.
> 
> Currently the Ada version is smaller than the C version
> and it is just luck that something important isn't
> overwritten and we get a simple crash.
> 
> The other pthread_*_attr_t structures should be double
> checked as well.
> 

Yes, I already have that change locally in newlib, it solves the stack 
corruption issue, but the program still fails to run properly.
With the gnatD-option Arnaud suggested I figured the following today:

Complete_Master is called from finalizer of the procedure Hello. At the start 
it calls STPO.Self to get the id of the current task. It should be the id of 
the Ada-main task, but it's the id of the subordinate hello_task.
Then, of course, Complete_Master does not work properly.  rtems STPO.Self 
essentially calls rtems_task_self(). So either this function returns wrong ids 
or the context switch is not handled properly.
The gnat-rts uses the posix-API, but rtems_task_self is from the classic API. 
Could it produce problems if one mixes them?

For testing I added a 2nd task to the example and printed the result of 
STPO.Self at several places of the program. Depending on the order of 
declaration of the tasks I got different results, but never the right ones.
Tomorrow I will take a rtems-posix-example and see if I get proper ids if I 
call rtems_task_self from within the posix-threads.

@Arnaud: I saw quite a lot of #pragma Debug-lines in the rts-code. Is there a 
simple way of activating them without having to recompile gnat?

Best regards,

Jan

> --joel sherrill
> 
> On 10/25/2015 12:59 PM, Arnaud Charlet wrote:
>  I would like to know from where Complete_Master is called to break there
>  and
>  find out why it uses the wrong id.
> >>>
> >>> Why don't you simply put a breakpoint on Complete_Master?
> >>
> >> That's how I found out about the wrong/weird Self_Id.
> >
> > Then you should also get a backtrace which will give you extra info.
> >
> >>> You can also build hello.adb with the -gnatD switch to debug at the code
> >>> expansion level where you'll see the call to Complete_Master.
> >>>
> >>
> >> Thank you, that option helps a lot. Will check out the generated code
> >> tomorrow.
> >
> > Glad to hear it.
> >
> > Arno
> >



Re: gnat 4.9.2 on arm with rtems

2015-10-26 Thread Jan Sommer
Am Monday 26 October 2015, 15:09:34 schrieb Joel Sherrill:
> 
> On 10/26/2015 3:02 PM, Jan Sommer wrote:
> > Am Monday 26 October 2015, 08:26:57 schrieb Joel Sherrill:
> >> Hi
> >>
> >> I am on travel this week but I thought we had this problem
> >> solved. I poked on a build server I used but can't find
> >> the change and it doesn't look to be committed.
> >>
> >
> > Yes, it was me back then too ;-)
> > I have been occupied the last months.
> >
> >> The issue was that the contents of read_attr_t has changed
> >> and the Ada definition of the same structure needs to be
> >> updated. This is defined in pthread.h in newlib or an
> >> installed tools. The Ada version is in
> >> gcc/ada/s-osinte-rtems.ads.
> >>
> >> Currently the Ada version is smaller than the C version
> >> and it is just luck that something important isn't
> >> overwritten and we get a simple crash.
> >>
> >> The other pthread_*_attr_t structures should be double
> >> checked as well.
> >>
> >
> > Yes, I already have that change locally in newlib, it solves the stack 
> > corruption issue, but the program still fails to run properly.
> > With the gnatD-option Arnaud suggested I figured the following today:
> 
> Just double checking the language. The change I suggested was
> in the gcc/ada directory to an RTEMS specific OS interface file
> to change the Ada definition of pthread_attr_t to match the
> definition of the one in newlib.
> 

Exactly, I have changes in gcc-4.9.2/gcc/ada/s-osinte-rtems.ads and I have one 
small change in newlib-2.2.0.20150423/newlib/libc/sys/rtems/sys/cpuset.h .
I can send the patches to you tomorrow if you want.


> > Complete_Master is called from finalizer of the procedure Hello. At the 
> > start it calls STPO.Self to get the id of the current task. It should be 
> > the id of the Ada-main task, but it's the id of the subordinate hello_task.
> > Then, of course, Complete_Master does not work properly.  rtems STPO.Self 
> > essentially calls rtems_task_self(). So either this function returns wrong 
> > ids or the context switch is not handled properly.
> > The gnat-rts uses the posix-API, but rtems_task_self is from the classic 
> > API. Could it produce problems if one mixes them?
> 
> There shouldn't be anything in the RTEMS GNAT target code to call
> rtems_task_self(). There is a call to something like gnat_task_self()
> and you need --enable-ada (and --disable-tests) on the RTEMS
> configure command like to enable that library. This method returns
> the value Ada.Self() expects.
> 

My bad. It's rtems_ada_self(), you are right. The problem is still, that it 
returns the address to the wrong ATCB. I will try to find out more tomorrow.

> FWIW this implementation is find for uniprocessors but not SMP.
> It should be changed to a POSIX key or thread local storage so
> it is SMP safe.
> 

I only use the RaspberryPi1., so there shouldn't be any SMP-problems.

> > For testing I added a 2nd task to the example and printed the result of 
> > STPO.Self at several places of the program. Depending on the order of 
> > declaration of the tasks I got different results, but never the right ones.
> > Tomorrow I will take a rtems-posix-example and see if I get proper ids if I 
> > call rtems_task_self from within the posix-threads.
> 
> pthread_self() and rtems_task_self() should return exactly the same
> value when in the same task. If they do not, something is horribly
> broken.
> 
> > @Arnaud: I saw quite a lot of #pragma Debug-lines in the rts-code. Is there 
> > a simple way of activating them without having to recompile gnat?
> >
> > Best regards,
> >
> >  Jan
> >
> >> --joel sherrill
> >>
> >> On 10/25/2015 12:59 PM, Arnaud Charlet wrote:
> >>>>>> I would like to know from where Complete_Master is called to break 
> >>>>>> there
> >>>>>> and
> >>>>>> find out why it uses the wrong id.
> >>>>>
> >>>>> Why don't you simply put a breakpoint on Complete_Master?
> >>>>
> >>>> That's how I found out about the wrong/weird Self_Id.
> >>>
> >>> Then you should also get a backtrace which will give you extra info.
> >>>
> >>>>> You can also build hello.adb with the -gnatD switch to debug at the code
> >>>>> expansion level where you'll see the call to Complete_Master.
> >>>>>
> >>>>
> >>>> Thank you, that option helps a lot. Will check out the generated code
> >>>> tomorrow.
> >>>
> >>> Glad to hear it.
> >>>
> >>> Arno
> >>>
> >
> 
> 



Re: gnat 4.9.2 on arm with rtems

2015-10-28 Thread Jan Sommer
Top post:

I got it working. The Set function was always overwriting the address of the 
previous ATCB, so STPO.Self was always returning the ATCB of the task created 
last.
It turns out that I was building rtems without the --enable-ada option. The 
option is not mentioned in configure --help and gnat still builds fine.

Would it be possible to not have the symbol rtems_task_self if the --enable-ada 
switch is off? Then linking gnat should fail with an undefined reference.
I don't know too much of the rtems internals, but maybe it is as easy as adding 
ifdefs around the SCORE_EXTERN void *rtems_ada_self in score/threadimpl.h?

@Joel: What shall I do about the changes I made to gcc/ada/s-osinte-rtems.ads 
and newlib/libc/sys/rtems/sys/cpuset.h ? Just send the patches to you or should 
I  push them to the respective lists with you CC?

Best regards,

Jan

Am Monday 26 October 2015, 17:04:53 schrieb Joel Sherrill:
> 
> On October 26, 2015 5:02:07 PM EDT, Jan Sommer 
>  wrote:
> >Am Monday 26 October 2015, 15:09:34 schrieb Joel Sherrill:
> >> 
> >> On 10/26/2015 3:02 PM, Jan Sommer wrote:
> >> > Am Monday 26 October 2015, 08:26:57 schrieb Joel Sherrill:
> >> >> Hi
> >> >>
> >> >> I am on travel this week but I thought we had this problem
> >> >> solved. I poked on a build server I used but can't find
> >> >> the change and it doesn't look to be committed.
> >> >>
> >> >
> >> > Yes, it was me back then too ;-)
> >> > I have been occupied the last months.
> >> >
> >> >> The issue was that the contents of read_attr_t has changed
> >> >> and the Ada definition of the same structure needs to be
> >> >> updated. This is defined in pthread.h in newlib or an
> >> >> installed tools. The Ada version is in
> >> >> gcc/ada/s-osinte-rtems.ads.
> >> >>
> >> >> Currently the Ada version is smaller than the C version
> >> >> and it is just luck that something important isn't
> >> >> overwritten and we get a simple crash.
> >> >>
> >> >> The other pthread_*_attr_t structures should be double
> >> >> checked as well.
> >> >>
> >> >
> >> > Yes, I already have that change locally in newlib, it solves the
> >stack corruption issue, but the program still fails to run properly.
> >> > With the gnatD-option Arnaud suggested I figured the following
> >today:
> >> 
> >> Just double checking the language. The change I suggested was
> >> in the gcc/ada directory to an RTEMS specific OS interface file
> >> to change the Ada definition of pthread_attr_t to match the
> >> definition of the one in newlib.
> >> 
> >
> >Exactly, I have changes in gcc-4.9.2/gcc/ada/s-osinte-rtems.ads and I
> >have one small change in
> >newlib-2.2.0.20150423/newlib/libc/sys/rtems/sys/cpuset.h .
> >I can send the patches to you tomorrow if you want.
> >
> >
> >> > Complete_Master is called from finalizer of the procedure Hello. At
> >the start it calls STPO.Self to get the id of the current task. It
> >should be the id of the Ada-main task, but it's the id of the
> >subordinate hello_task.
> >> > Then, of course, Complete_Master does not work properly.  rtems
> >STPO.Self essentially calls rtems_task_self(). So either this function
> >returns wrong ids or the context switch is not handled properly.
> >> > The gnat-rts uses the posix-API, but rtems_task_self is from the
> >classic API. Could it produce problems if one mixes them?
> >> 
> >> There shouldn't be anything in the RTEMS GNAT target code to call
> >> rtems_task_self(). There is a call to something like gnat_task_self()
> >> and you need --enable-ada (and --disable-tests) on the RTEMS
> >> configure command like to enable that library. This method returns
> >> the value Ada.Self() expects.
> >> 
> >
> >My bad. It's rtems_ada_self(), you are right. The problem is still,
> >that it returns the address to the wrong ATCB. I will try to find out
> >more tomorrow.
> 
> There is a comparable set method. If it isn't being called or isn't setting 
> the value correctly, the get can't work.
> 
> The method is simple. There is a special ada_self field in the RTEMS TCB 
> which is just storing the value so it is cheap to access.
> 
> >> FWIW this implementation is find for uniprocessors but not SMP.
> >> It should be changed to a POSIX key or threa

Re: __sync_-builtins cause undefined references on some sparc targets

2017-02-27 Thread Jan Sommer
On Montag, 27. Februar 2017 22:07:56 CET Eric Botcazou wrote:
> > "This __sync_() stuff seems to be used in several places in GCC. So,
> > changing libbacktrace is probably not enough. We need a general solution
> > for the __sync_() builtins on RTEMS. I don't think GCC can be changed to
> > emit __atomic_() calls for the __sync_() builtins (I would still try to
> > ask). The libgcc or libatomic is probably a good place to add them for
> > RTEMS as functions implemented via __atomic_() builtins."
> > 
> > Could someone give me some recommendations on what would be the best
> > solution to fix the problem and maybe some pointers on how to start?
> 
> I'm not sure backtrace support has much interest on embedded platforms and I 
> don't think implementing atomic operations makes any sense on LEON2, so the 
> best thing to do is probably to kludge around it in libgfortran.
> 

Is there an easy way to remove the libbacktrace dependency?
Might something like that work?: https://patchwork.ozlabs.org/patch/553017/