This is the mail archive of the
gcc@gcc.gnu.org
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: Sebastian Huber <sebastian dot huber at embedded-brains dot de>, Jan Sommer <soja-lists at aries dot uberspace dot de>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 29 Oct 2015 07:47:28 -0500
- Subject: Re: gnat 4.9.2 on arm with rtems
- Authentication-results: sourceware.org; auth=none
- References: <7240505 dot X6MuHlINPd at kubuntu> <5675608 dot 1aALmrqTrt at kubuntu> <2C374C6C-1183-4F0D-9DF4-7AD574462DB1 at oarcorp dot com> <1527588 dot 3E1Hr2Vsep at kubuntu> <5631F8F4 dot 9060706 at embedded-brains dot de>
On 10/29/2015 5:46 AM, Sebastian Huber wrote:
On 28/10/15 15:22, Jan Sommer wrote:
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?
Since you work on this area, this task variable should go way, since its
broken on SMP systems. I would replace it
o with functions, e.g. rtems_ada_get_self() and
rtems_ada_set_self(), or
o POSIX keys, or
o thread-local storage.
POSIX keys and thread-local storage would make the --enable-ada option
superfluous. Thread-local storage is more efficient. It is well
supported on ARM, PowerPC and SPARC on RTEMS.
This is the best long term solution and shouldn't add any overhead. Ada
is not supported by all gcc target architectures and I think ARM, PowerPC,
SPARC, and x86 are likely the only architectures anyone will care to use
it on. If that statement is wrong, then they can fix TLS on the next
architecture.
FWIW this has a ticket for RTEMS: https://devel.rtems.org/ticket/2289
Since this is a change against gcc 4.9 and other branches, it should
also have a gcc PR. Both PRs should reference each other.
Having an RTEMS PR makes it appropriate to add to the RTEMS 4.11 branch
as well. This shouldn't have a negative impact. The configure magic
will likely be the hardest thing to review since we probably can
drop a configure option (--enable-ada) and tune --enable-ada-tests
or whatever that is. It also may make sense to force --enable-ada-tests
to only build on architectures with real TLS and Ada support.
@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?
Please send them as patches to the corresponding lists and CC
devel@rtems.org.
--joel