I am trying to compile a bare-metal ARM Cortex-M3 program with clang. (Code and linker script work fine with gcc.)
My issue is that clang seems to emit a section .ARM.exidx whether it is needed or not.
Since for my code, gcc did not emit a .ARM.exidx section, my linker script thus does not specify a region for it. clang however seems to emit it as indicated by this error message:
ld.lld: error: no memory region specified for section '.ARM.exidx'
clang: error: ld.lld command failed with exit code 1 (use -v to see invocation)
Is there any way to avoid generating this section when it is not needed?
I tried the options -fno-unwind-tables and -fno-exceptions but it seems to be a known bug that they do not work as expected. See these pull requests: D31139 and D31140
I am currently working around this issue with the following section defition in the linker script:
/DISCARD/ :
{
*(.ARM.exidx)
}
That seems a bit fragile though since the section will be missing if due to any changes to the code, the section is required at a later point.
Related
I'm trying to build the Contiki OS for a custom platform (based on the EZR32LG MCU) with GCC compiler.
When I make the project it runs with a few warnings about '#pragma GCC diagnostic'. (I don't know if this is relevant, but I'm just providing the information to be complete)
After a few warnings, the compilation stops and returns:
/tmp/ccY4OiVd.s: Assembler messages:
/tmp/ccY4OiVd.s:37: Error: garbage following instruction -- `dsb 0xF'
/tmp/ccY4OiVd.s:51: Error: garbage following instruction -- `dsb 0xF'
make: *** [obj_slwstk6201a/watchdog.o] Error 1
I looked at the dsb instruction, but I'm not finding much except that this ensures that all explicit data memory transfer before the DSB are complete before any instruction after the DSB is executed.
Googling the error did not return many results, the only thing I found was that maybe my binutils version is outdated. I checked with ld --version, which returns 2.24. The latest release is 2.28, but I can't find a way to update the GCC version to use binutils 2.28.
So I downloaded GCC -v6, but the ld -v command still returns 2.24.
I'm not sure if this would resolve the error, or I'm completely wrong about the origin of the error..
I'm linking with FreeScale Code Warrior 5.9 for MPC5554, which is a PPC chip with an e500mc core. I'm compiling with GCC 4.6.4 compiled for powerpc-none-eabi.
I am compiling some C code for my project, including the file with main, using a GCC cross compiler. I need to link using Code Warrior, though. GCC adds a call to a function called __eabi at the start of main, which is supposed to initialize a couple of registers. It cannot be removed, and is unnecessary for what I'm doing. GCC expects it to be provided by the crt.
These are my compile flags for GCC:
-O2 -std=c99 -w -mno-eabi -mregnames -mcpu=e500mc -misel=yes -mfloat-gprs=single -mno-string -msdata=none
The documentation for GCC PowerPC says there is a -no-eabi argument, which should remove this, but then if you dig into it there are a number of bugs reports pointing out that the documentation is wrong and the flag does not actually remove the call to __eabi.
I tried simply adding an __eabi function to the crt from CodeWarrior. In __ppc_eabi_init.c I added the function:
asm extern void __eabi(void)
{
addis r13,r0,_SDA_BASE_#h
ori r13,r13,_SDA_BASE_#l
addis r2,r0,_SDA2_BASE_#h
ori r2,r2,_SDA2_BASE_#l
blr
}
However, when I try to link, I still get the error that __eabi from main in main.o is undefined. It seems the Code Warrior linker can't find my function. I verified that __ppc_eabi_init.c is first in the link order.
How can I get this to link? Is there a way to remove the call to __eabi? Why is Code Warrior unable to find the function when I provide it?
It turned out that I had the right idea, but that I was accidentally putting the __eabi function definition inside an #ifdef block that was being excluded from assembly. When I moved the definition outside this block it linked properly.
I also modified the provided linker scripts so they would correctly locate the .rodata.cst* sections that GCC uses for read-only data. I am not sure this was important, but I was getting a warning from the linker, so I fixed it.
In MPC5554.lcf, I changed
.rodata (CONST) : {
*(.rdata)
*(.rodata)
}
to read
.rodata (CONST) : {
*(.rdata)
*(.rodata)
*(.rodata.cst*)
}
Using avr-gcc and attempting to reduce size of binary using -ffunction-sections and -fdata-sections when compiling and linking with --gc-sections. The .lds file contains nothing:
SECTIONS
{
}
This error occurs when partial linking many .o's into a .a, which will then be used later to complete the build.
I've read through some other posts that discuss these options, but nothing that clarifies the ENTRY() issue. Their doesn't seem to be a need for it at the partial stage before trying to reduce code size(pre-existing linker script clearly doesn't use it).
Documentation states : --gc-sectionts
"This option can be set when doing a partial link (enabled with option '-r'). In this case the root of symbols kept must be explicitly specified either by an '--entry' or `--undefined' option or by a ENTRY command in the linker script."
This is where I'm lost. Would greatly appreciate some more explanation of how to use --undefined, --entry, or ENTRY cmd in linker script to resolve this issue.
I had a similar issue and gave up. I ended up compiling with the -fwhole-program option enabled which significantly reduced the size of my bootloader.
i'm trying to resurrect an old installation of Gentoo Linux that has kernel 2.6.32 and i could update #system with an exception: gcc 4.5.4 failed installation.
The last lines are here:
http://pastebin.com/8s4z0FJy
Ask me if you need more info, i'll post something more when i get home (Got that info through SSH).
Even GHC fails compiling but i'll handle that later. I need GCC in order to compile the other packages.
Thanks in advance
To respond to a link with another link from googling: https://forums.gentoo.org/viewtopic-t-896518-start-0.html. Let me summarize that thread:
{standard input}: Assembler messages:
{standard input}:87553: Warning: end of file not at end of a line; newline inserted
{standard input}:88534: Error: unknown pseudo-op: `.l38'
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
xgcc: Internal error: Killed (program cc1)
Basically, the assembly errors come because gcc’s assembly output was interrupted when it was killed. The Gentoo forums thread suggests this may likely be because gcc used up too much memory. You can confirm this by checking near the end of dmesg’s output for OOM stuff. If memory is not the issue, then you might have a real bug and should follow the instructions in the text you pastebined for reporting the bug to https://bugs.gentoo.org/. But, please try seeing if memory is the issue first.
If memory is the issue, make sure that you have swap partitions on your machine and that they are enabled. You can view a summary of your enabled swap partitions by running swapon -s. If nothing shows up and you cannot repartition, you can always use a trick like # ( umask 0077 && dd if=/dev/zero of=/.swap.img bs=1M count=1024 && mkswap /.swap.img && swapon /.swap.img ) (the ‘#’ indicates a root shell prompt, so don’t actually type it). The forum thread also suggests that removing -pipe, which causes gcc to use more memory instead of writing out lots of temporary files, from CFLAGS and CXXFLAGS (by editing /etc/make.conf or /etc/portage/make.conf, whichever exists). We cannot tell what your CFLAGS are from what you posted.
I am trying to compile source of milcv7.7.8/ks_spectrum on a cluster with MPICC using version 11.1 20090511 when make the source in milcv7.7.8/ks_spectrum by 'make ks_spectrum_hisq' command then at last the error comes out as
com_mpi.o: In function initialize_machine':
../generic/com_mpi.c:(.text+0xb447): undefined reference to_mm_idivrem_epi32'
I know now that this function _mm_idivrem_epi32 is a part of ia32intrin.h file in intel compiler.
When I use the latest intel mpiicc on new cluster with 14.0.0 20130728 version of intel compiler then code compiles successfully.
So is there any way to tell linker to include function _mm_idivrem_epi32 location...
_mm_idivrem_epi32() is not a function but rather a compiler intrinsic. When properly handled, it is replaced with a call to __svml_idivrem4() from the Intel's Short Vector Math Library libsvml.
You are most likely being hit by a bug in ICC's auto-vectoriser. Try compiling the same source file with -no-vec and see it this has any effect. Or better use the newest ICC version that you have at your disposal.