• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 24 subscribers
  • Views 10262 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

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.