GCC 4.8 now generates debug information in DWARF-4 format by default. Use of option -gdwarf-2 will force gcc to generate debug information in DWARF-2 format. This is required for example in order to debug gcc compiled code with the MetaWare debugger. In some case, ARC users may find some section are still in DW4 format and can not be interpreted by downstream tools like objdump.

Example:

$ arc-elf32-gcc -gdwarf-2 -mARC700 hello.c $ arc-elf32-gcc --version arc-elf32-gcc (ARCompact elf32 toolchain (built 20130620)) 4.8.0 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ arc-elf32-objdump -g -G a.out >/dev/null arc-elf32-objdump: Warning: CU at offset 93 contains corrupt or unsupported version number: 4. arc-elf32-objdump: Warning: CU at offset 985 contains corrupt or unsupported version number: 4. ....... Skipping similiar lines ....... arc-elf32-objdump: Warning: CU at offset ba12 contains corrupt or unsupported version number: 4. arc-elf32-objdump: Warning: CU at offset c3ba contains corrupt or unsupported version number: 4. arc-elf32-objdump: Warning: There are 16642 unused bytes at the end of section .debug_loc arc-elf32-objdump: Error: No range lists in .debug_info section! 

This problem only occurs after linking, and is seen when the library being linked in is built with 4.8 debug information(i.e. DWARF-4).

Users needing to work in a purely DWARF-2 environment need to build the library with DWARF-2 debug information as well. The build-all.sh argument --target-cflags can be used to achieve this.

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

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.

“target sim” command fails with the following error message:

(gdb) target sim Target byte order unspecified unable to create simulator instance 

Manual entry as shown below does not exhibit the problem:

(gdb) target sim Connected to the simulator. 

When the target sim command is added in .gdbinit file the error is seen when the .gdbinit file is located in the user’s home folder (“~”).

If .gdbinit is placed in the current folder as a workaround, the target sim command works as expected.

Under certain debugging conditions, the gdb client program can be halted due to signals (SIG32, SIG33) received from libpthreads that can’t be handled by gdb since libraries are stripped of symbols.

These signals are not harmful and may be ignored. Add the following commands to .gdbinit file to ignore these signals:

handle SIG32 noprint nostop pass handle SIG33 noprint nostop pass 

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.

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.