This is the mail archive of the
mailing list for the GCC project.
Re: gnat 4.9.2 on arm with rtems
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Jan Sommer <soja-lists at aries dot uberspace dot de>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Cc: Arnaud Charlet <charlet at adacore dot com>
- Date: Mon, 26 Oct 2015 15:09:34 -0500
- Subject: Re: gnat 4.9.2 on arm with rtems
- Authentication-results: sourceware.org; auth=none
- References: <7240505 dot X6MuHlINPd at kubuntu> <20151025175934 dot GB1472 at adacore dot com> <562E2A21 dot 90201 at oarcorp dot com> <2229884 dot GfpZCCq4Px at kubuntu>
On 10/26/2015 3:02 PM, Jan Sommer wrote:
Am Monday 26 October 2015, 08:26:57 schrieb Joel Sherrill:
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
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.
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.
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.
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
@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?
On 10/25/2015 12:59 PM, Arnaud Charlet wrote:
I would like to know from where Complete_Master is called to break there
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
Glad to hear it.
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985