__sync_-builtins cause undefined references on some sparc targets

__sync_-builtins cause undefined references on some sparc targets

[Jan.Sommer]

Hello,

I compiled the gcc 6.3.0 for the leon2 processor for RTEMS (i.e. sparc-rtems4.12-*). When linking a fortran program for the leon2 processor I get undefined references for `__sync_bool_compare_and_swap_4' (see below).
According to the discussion on the rtems mailinglist the __sync_*-operations are legacy and __atomic_*-operations should be used instead or to quote:

"This __sync_() stuff seems to be used in several places in GCC. So, changing libbacktrace is probably not enough. We need a general solution for the __sync_() builtins on RTEMS. I don't think GCC can be changed to emit __atomic_() calls for the __sync_() builtins (I would still try to ask). The libgcc or libatomic is probably a good place to add them for RTEMS as functions implemented via __atomic_() builtins."

Could someone give me some recommendations on what would be the best solution to fix the problem and maybe some pointers on how to start?

I put the rtems mailinglist CC, so they can comment as well.


sparc-rtems4.12-gcc -B../../../../../leon2/lib/ -specs bsp_specs -qrtems -mcpu=cypress -mhard-float -O2 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs  -Wl,--gc-sections  -mcpu=cypress -mhard-float   -o ticker.exe init.o tasks.o -L/localdata/somm_ja/rtems-fortran/install/bsps/4.12/sparc/sparc-rtems4.12/leon2/lib/ -llapack -lrefblas -ltmglib -lcblas -lm -lgfortran -lgcc
/localdata/somm_ja/rtems-fortran/install/tools/4.12/sparc/lib/gcc/sparc-rtems4.12/6.3.0/libgfortran.a(elf.o): In function `backtrace_initialize':
/localdata/somm_ja/rtems-fortran/rtems-source-builder/rtems/build/sparc-rtems4.12-gcc-6.3.0-newlib-2.5.0-x86_64-linux-gnu-1/build/sparc-rtems4.12/libbacktrace/../../../gcc-6.3.0/libbacktrace/elf.c:960: undefined reference to `__sync_bool_compare_and_swap_4'
/localdata/somm_ja/rtems-fortran/install/tools/4.12/sparc/lib/gcc/sparc-rtems4.12/6.3.0/libgfortran.a(elf.o): In function `elf_add_syminfo_data':
/localdata/somm_ja/rtems-fortran/rtems-source-builder/rtems/build/sparc-rtems4.12-gcc-6.3.0-newlib-2.5.0-x86_64-linux-gnu-1/build/sparc-rtems4.12/libbacktrace/../../../gcc-6.3.0/libbacktrace/elf.c:456: undefined reference to `__sync_bool_compare_and_swap_4'
/localdata/somm_ja/rtems-fortran/install/tools/4.12/sparc/lib/gcc/sparc-rtems4.12/6.3.0/libgfortran.a(dwarf.o): In function `backtrace_dwarf_add':
/localdata/somm_ja/rtems-fortran/rtems-source-builder/rtems/build/sparc-rtems4.12-gcc-6.3.0-newlib-2.5.0-x86_64-linux-gnu-1/build/sparc-rtems4.12/libbacktrace/../../../gcc-6.3.0/libbacktrace/dwarf.c:3030: undefined reference to `__sync_bool_compare_and_swap_4'
collect2: error: ld returned 1 exit status
Makefile:627: recipe for target 'ticker.exe' failed
make: *** [ticker.exe] Error 1

Best regards,

   Jan


Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Simulation and Software Technology | Software for Space Systems and Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer
Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.sommer@dlr.de
DLR.de/SC

Re: __sync_-builtins cause undefined references on some sparc targets

[Eric Botcazou]

> "This __sync_() stuff seems to be used in several places in GCC. So,
> changing libbacktrace is probably not enough. We need a general solution
> for the __sync_() builtins on RTEMS. I don't think GCC can be changed to
> emit __atomic_() calls for the __sync_() builtins (I would still try to
> ask). The libgcc or libatomic is probably a good place to add them for
> RTEMS as functions implemented via __atomic_() builtins."
> 
> Could someone give me some recommendations on what would be the best
> solution to fix the problem and maybe some pointers on how to start?

I'm not sure backtrace support has much interest on embedded platforms and I 
don't think implementing atomic operations makes any sense on LEON2, so the 
best thing to do is probably to kludge around it in libgfortran.

-- 
Eric Botcazou

Re: __sync_-builtins cause undefined references on some sparc targets

[Jan Sommer]

On Montag, 27. Februar 2017 22:07:56 CET Eric Botcazou wrote:
> > "This __sync_() stuff seems to be used in several places in GCC. So,
> > changing libbacktrace is probably not enough. We need a general solution
> > for the __sync_() builtins on RTEMS. I don't think GCC can be changed to
> > emit __atomic_() calls for the __sync_() builtins (I would still try to
> > ask). The libgcc or libatomic is probably a good place to add them for
> > RTEMS as functions implemented via __atomic_() builtins."
> > 
> > Could someone give me some recommendations on what would be the best
> > solution to fix the problem and maybe some pointers on how to start?
> 
> I'm not sure backtrace support has much interest on embedded platforms and I 
> don't think implementing atomic operations makes any sense on LEON2, so the 
> best thing to do is probably to kludge around it in libgfortran.
> 

Is there an easy way to remove the libbacktrace dependency?
Might something like that work?: https://patchwork.ozlabs.org/patch/553017/

Re: __sync_-builtins cause undefined references on some sparc targets

[Eric Botcazou]

> Is there an easy way to remove the libbacktrace dependency?
> Might something like that work?: https://patchwork.ozlabs.org/patch/553017/

Yes, even better, simply arrange for the __sync and __atomic support tests of 
libbacktrace to fail on your target, possibly by using the same trick as HPUX.

-- 
Eric Botcazou

RE: __sync_-builtins cause undefined references on some sparc targets

[Jan.Sommer]

> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
> Eric Botcazou
> Sent: Monday, February 27, 2017 10:30 PM
> To: Jan Sommer
> Cc: gcc@gcc.gnu.org; devel@rtems.org
> Subject: Re: __sync_-builtins cause undefined references on some sparc targets
> 
> > Is there an easy way to remove the libbacktrace dependency?
> > Might something like that work?:
> > https://patchwork.ozlabs.org/patch/553017/
> 
> Yes, even better, simply arrange for the __sync and __atomic support tests of
> libbacktrace to fail on your target, possibly by using the same trick as HPUX.

Ok. I set libbacktrace_cv_sys_sync=no for my target and the undefined referenced disappeared.
However I am not sure I understand what that means now.
Is libbacktrace excluded from the build, or is it build but broken?

Cheers,

   Jan


> 
> --
> Eric Botcazou

Re: __sync_-builtins cause undefined references on some sparc targets

[Eric Botcazou]

> Is libbacktrace excluded from the build, or is it build but broken?

Neither, it's presumably falls back to __atomic.  No big deal in any case, 
since you'll presumably never use libbacktrace in practice.

-- 
Eric Botcazou

Re: __sync_-builtins cause undefined references on some sparc targets

[Sebastian Huber]

On 03/03/17 13:23, Eric Botcazou wrote:
>> Is libbacktrace excluded from the build, or is it build but broken?
> Neither, it's presumably falls back to __atomic.  No big deal in any case,
> since you'll presumably never use libbacktrace in practice.
>

We have (libgcc/config/gthr-rtems.h)

static inline int
__gthread_active_p (void)
{
   return 1;
}

and (libgfortran/runtime/backtrace.c)

void
show_backtrace (bool in_signal_handler)
{
   struct backtrace_state *lbstate;
   struct mystate state = { 0, false, in_signal_handler };

   lbstate = backtrace_create_state (NULL, __gthread_active_p (),
                     error_callback, NULL);

and (libgfortran/runtime/backtrace.c)

struct backtrace_state *
backtrace_create_state (const char *filename, int threaded,
             backtrace_error_callback error_callback,
             void *data)
{
   struct backtrace_state init_state;
   struct backtrace_state *state;

#ifndef HAVE_SYNC_FUNCTIONS
   if (threaded)
     {
       error_callback (data, "backtrace library does not support 
threads", 0);
       return NULL;
     }
#endif

So, I doubt this works for RTEMS.

I guess libgfortran needs an option to be a bit less verbose on some 
targets.

-- 
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@embedded-brains.de
PGP     : Public key available on request.

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