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