Known Issues: GNU Toolchain for DWC ARC Processors, v2015.06
There is a limitation with the Eclipse IDE for GNU toolchain on linux hosts where it only supports uClibc toolchain for ARC HS Processors. Due to existing technical limitations, it is not possible to provide both ARC HS and ARC 700 toolchains under linux host at the moment. Due to another technical limitation, we cannot hide ARC 700 projects, which may mislead the user (hence this known issue).
Users wanting to use the IDE with ARC700 uClibC toolchain can add the toolchain manually. Please file an issue on github if you need any support in doing this.
When debugging multi-threaded applications, when GDB is given command "next" or "step" it might just resume application instead of stepping a line. Depending on presence of other breakpoints in application, application will either run to the end, or will run until hitting one of those breakpoints.
This issue happens due to fallacy of GDB logic in handing of architectures that use software single instruction step - that means that breakpoints are used to do single instruction steps (those are used internally by GDB to do a source line step), however in some cases with multi-threaded applications those breakpoints are removed by the time GDB tries to confirm that thread has been stopped by breakpoint. Absence of breakpoint at expected location causes grief in GDB and instead of continuing to do software single instruction steps, GDB just resumes thread, instead of doing an another single instruction step as it would have.
Code that affects this behaviour has been modified in GDB after 7.9 release, and latest master GDB master branch doesn't experience that issues that often, although it hasn't been removed completely at the moment of writing.
Possible workaround is to not use "step" and "next" commands and use only manual breakpoints and "continue" command. "stepi" and "nexti" command should work as well.
GCC's link time optimization feature in 4.8 has not yet been ported to ARC.
Do not compile with -flto options.
When debugging user space programs on Linux via GDB, users may notice GDB warning messages indicating "Could not load shared symbols for ." This warning happens when gdbserver is invoked with non-full path for the target binary, for example gdbserver :10000 hello. Gdbserver works fine with this invocation and resolves the binary location using PATH however the GDB client emits the warning.
There are no negative effects from these messages and debugging works fine.
Start gdbserver with full path to target program, for example gdbserver :10000 /usr/bin/hello.
The –fPIE option is not yet supported in the uclibc port for ARC GNU and use of the option may result in seg faults.
Don’t use –fPIE.
According to gcc.gnu.org/onlinedocs/gcc/Link-Options.html, -nostdlib should not link libgcc but previous releases of ARC GNU toolchain linked libgcc regardless under this option. The ARC GNU toolchain supported option –reallynostdlib for –nostdlib behavior.
In ARC GNU 4.8 the –reallynostdlib has been deprecated and the toolchain implements standard –nostdlib behavior, meaning libgcc is not linked under –nostdlib.
The GCC documentation explicitly mentions that users usually still need libgcc when wanting to avoid other standard libraries. The recommendation is for users to specify –lgcc as well when specifying –nostdlib to avoid any problems.
Turning on the use of the frame pointer via the –fno-omit-frame-pointer option can result in crashes.
The work-around is to enable -fomit-frame-pointer.
Dynamically linked ARC Linux user applications may fail for kernels configured for a page size of 16K (default is 8K) Enabling 16k page size support in the ARC GNU toolchain requires the elf loadable segments (program segments) to be mapped at 16k boundary (the current alignment is 4k) which causes the kernel to fail when loading the main executable (in both static and dynamically linked scenarios).
The work-around is to use linker option -Wl,-z,max-page-size=16384