-
Notifications
You must be signed in to change notification settings - Fork 48
Known Issues: GNU Toolchain for DWC ARC Processors v4.8 R1
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.