Undefined reference to `__sync_bool_compare_and_swap_4' for some Leon configurations with gfortran

[Sebastian Huber]

On 03/03/17 11:13, Jan.Sommer at dlr.de wrote:
>> -----Original Message-----
>> From: Sebastian Huber [mailto:sebastian.huber at embedded-brains.de]
>> Sent: Wednesday, March 01, 2017 7:47 AM
>> To: Sommer, Jan; devel at 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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.