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 isreported 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 differentflags 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
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'
// 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;
class A
{
int m_i;
public:
A(int i) : m_i(i) { }
A(int i) : m_i(i)
}
int value(int x) { return m_i + x; }};
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);
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);}
return a.value(x);
int main(int argc, char* argv[]){ return use_static_inst(argc);}
int main(int argc, char* argv[])
return use_static_inst(argc);
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
I was experiencing this issue as well on Arch, the same GCC version omegle.
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.
-fno-exceptions
Hello, thanks for the information.
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 itis going to emit code for a platform, that requires memory barriers (sincethere might be out of order memory accesses by multiple cores) but on the otherhand it doesn't actually supply the function to implement such a barrier.
There was a discussion over at Stack Overflow about this.
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.