On 03/03/17 11:13, jan.som...@dlr.de wrote:
-----Original Message-----
From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
Sent: Wednesday, March 01, 2017 7:47 AM
To: Sommer, Jan; devel@rtems.org
Subject: Re: Undefined reference to `__sync_bool_compare_and_swap_4' for
some Leon configurations with gfortran
[...]
I updated the __sync-check of libbacktrace and now the undefined references
are gone and my test program compiles.
If there are no objections I would try to push something like the attached
patch upstream. Do you have any suggestions to which branches?
I thought about trunk and the gcc-6 branch or do we need further backports
for older RTEMS versions?
I don't think this is the way to go. Firstly, this is certainly not a
SPARC-specific
problem.
Secondly, RTEMS is multi-threaded, are you sure you can simply disable
this feature?
Well, the patch only disabled the feature in the configuration of libbacktrace.
If I understand autotools correctly, this shouldn't affect other parts of gcc,
i.e.
if the builtins are used there they should still show up as undefined
references.
Yes, you disable it in libbacktrace. Will libbacktrace work correctly in
this case?
RTEMS supports C11 atomic operations which includes libatomic
support. However, we lack the
__sync_* builtin support on targets without atomic operations in hardware. This
is the problem we should fix. We should provide these functions either in libgcc
or in libatomic.
I was afraid you would say that ;-). However, I am not sure I would know
where/how to start.
We have to figure out where to add it. In libgcc similar to
https://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/config/nios2/linux-atomic.c?revision=243994&view=markup
https://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/sync.c?revision=243994&view=markup
or in libatomic. Adding it to libatomic is more work, however, the
resulting functions are a bit more efficient.
In libgcc you can for example do this (use a macro to generate the variants)
typedefunsignedintUQItype__attribute__((mode(QI)));
UQItype __sync_fetch_and_add_1(UQItype *ptr, UQItype val)
{
__atomic_fetch_add(ptr, val, |__ATOMIC_SEQ_CST);|
}
One open question is why is there a libbacktrace dependency in libgfortran?
Does this add any value to embedded targets?
I don't think so. That's why I assumed it would be safe to change the
configuration of libbacktrace
in order to get the fortran program to compile.
If you don't think its useful for embedded targets, then maybe
libgfortran should simply not use libbacktrace at all, e.g. for RTEMS
targets. I guess it is used to generate fancy error messages.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
