• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 23 subscribers
  • Views 10408 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to solve: undefined reference to `__sync_synchronize'

Rocco Matano

I am trying to update the tool-chain for a bare metal embedded project. We are building on windows an up to now we have been using version 5.4.1 20160609 (release) [ARM/embedded-5-branch revision 237715].

Now I am trying version 9.3.1 20200408 (release) (9-2020-q2-update), but I have an issue with an undefined symbol while linking: __sync_synchronize is
reported as missing and I have no idea from which source this symbol should be resolved. Do I have to link a library that I am missing? Should I give different
flags to the compiler so that it generates the code for that function?

Below is a sample that compiles and links just fine with the old tool-chain, but fails with the new one. In both cases this command line was used:

arm-none-eabi-g++ -mthumb -specs=nosys.specs sample.cpp

The exact failure message is:
c:/projects/cpt_tools/gcc-arm-none-eabi/9.3.1/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\RMatano\AppData\Local\Temp\ccSZkMXN.o: in function `use_static_inst(int)':
synch.cpp:(.text+0xc): undefined reference to `__sync_synchronize'
collect2.exe: error: ld returned 1 exit status

Here is the content of sample.cpp:

// compile with 'arm-none-eabi-g++.exe -mthumb -specs=nosys.specs sample.cpp'
//
// result: in function `use_static_inst(int)':
// synch.cpp:(.text+0x18): undefined reference to `__sync_synchronize'

class A
{
int m_i;

public:

A(int i) : m_i(i)
{
}

int value(int x)
{
return m_i + x;
}
};


int use_static_inst(int x)
{
// for this ctor the compiler generates a call to __sync_synchronize
static A a(0);

return a.value(x);
}

int main(int argc, char* argv[])
{
return use_static_inst(argc);
}

  • 0

    BTW: There is no difference when I run my test on Linux:

    rmatano@GERD1330-devbox:~/gcc-arm-none-eabi-9-2020-q2-update/bin$ ./arm-none-eabi-g++ -mthumb -specs=nosys.specs sample.cpp
    /media/persistent_storage/home/rmatano/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: /tmp/ccltslyj.o: in function `use_static_inst(int)':
/>sample.cpp:(.text+0xc): undefined reference to `__sync_synchronize'
collect2: error: ld returned 1 exit status
  • 0

    I was experiencing this issue as well on Arch, the same GCC version omegle.

  • 0

    Hi

    Some replies found on the web :

    " Your problem is caused by exception handling code that is produced by the compiler, which relies on runtime components - those are not present in your build.

    -fno-exceptions turns off exception handling in the code-generation of the compiler."

    Not sure to "-specs=nosys.specs", in case of cross-compile you need to specify a target arch like -march=armv7-a for sample.






  • 0 in reply to Jerome Decamps - 杜尚杰

    Hello,

    I can't imagine why one should think that this has something to do with exception handling.
    In fact adding the option `-fno-exceptions` doesn't change the outcome.

    I think the 'real' problem is that on the one hand the compiler decides it
    is going to emit code for a platform, that requires memory barriers (since
    there might be out of order memory accesses by multiple cores) but on the other
    hand it doesn't actually supply the function to implement such a barrier.

    There was a discussion over at Stack Overflow about this.

  • 0

    The insertion of a memory barrier is very likely due to this commit; diff.

    The get_guard_cond function now loads the 'guard' variable atomically if threadsafe is turned on. The compiler emits a __sync_synchronize call during this process.

    In the gcc source for the 5.4.1 20160609 release, this change is missing.

    I would check with gcc about this.

    Edit: Here is the atomic-load instruction emitted, followed by the __sync call.