This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gnat 4.9.2 on arm with rtems



On October 26, 2015 5:02:07 PM EDT, Jan Sommer <soja-lists@aries.uberspace.de> 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 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
>> >>>
>> >
>> 
>> 

--joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]