cross-compiling LM32 internal error while linking

Federico Vaga federico.vaga@gmail.com
Tue Feb 9 16:26:00 GMT 2016
Let me add other details. I removed my own crt0.S and linkerscript
and I still get this error:

/lm32-elf/bin/ld: internal error: addend should be zero for R_LM32_16_GOT

Following the code that trigger the problem

---------------
int main(int argc, char *argv[])
{
	return 0;
}
---------------


On Fri, Feb 05, 2016 at 06:30:45PM +0100, Federico Vaga wrote:
>Following another way to get the same error message.
>In this case it is enough to remove the line 'memset(&a, 0, sizeof(a));'
>to make the error disappear.
>
>-------------------------------------
>#include <string.h>
>#include <stdlib.h>
>
>struct test {
>	int a;
>	int b;
>	int c;
>};
>
>int main(int argc, char *argv[])
>{
>	struct test a;
>	int b;
>
>	memset(&a, 0, sizeof(a));
>	memset(&b, 0, sizeof(b));
>
>	return 0;
>}
>-------------------------------------
>
>Do you need also my linker script file?
>
>
>On Fri, Feb 05, 2016 at 03:58:05PM +0100, Federico Vaga wrote:
>>I think I got the source of the problem. I was writing the
>>simple testcase that you asked me:
>>
>>
>>#include <stdlib.h>
>>
>>int main(int argc, char *argv[])
>>{
>>	exit(0);
>>}
>>
>>
>>/bin/lm32-elf-gcc -c -o wrn-crt0.o wrn-crt0.S
>>/bin/lm32-elf-gcc -c -o rt-mturtle.o rt-mturtle.c
>>/bin/lm32-elf-gcc -c -o gcclm32-bug.o gcclm32-bug.c
>>/bin/lm32-elf-gcc -o gcclm32-bug.elf -nostartfiles wrn-crt0.o rt-mturtle.o gcclm32-bug.o -T wrnode.ld -lgcc -lc
>>/lib/gcc/lm32-elf/5.3.0/../../../../lm32-elf/bin/ld: internal error: addend should be zero for R_LM32_16_GOT
>>/lib/gcc/lm32-elf/5.3.0/../../../../lm32-elf/bin/ld: internal error: addend should be zero for R_LM32_16_GOT
>>
>>
>>
>>In the file rt-mturtle.c I have my syscall stubs in order to avoid errors like:
>>
>>newlib-2.2.0-1/newlib/libc/stdlib/exit.c:70: undefined reference to `_exit'
>>
>>
>>
>>The problem is with the errno 'variable'. According to:
>>
>>https://sourceware.org/newlib/libc.html#Stubs
>>
>>for function like fork(), I followed the example:
>>
>>#include <errno.h>
>>#undef errno
>>extern int errno;
>>int fork(void) {
>>errno = EAGAIN;
>>return -1;
>>}
>>
>>
>>
>>The errno trick of undefining the macro and set the an external variable causes
>>the error:
>>
>>/lib/gcc/lm32-elf/5.3.0/../../../../lm32-elf/bin/ld: internal error: addend should be zero for R_LM32_16_GOT
>>
>>
>>Of course. Now I'm able to compile without errors if I avoid to use errno. But
>>I do not thing is the right(tm) solution.
>>
>>On Fri, Feb 05, 2016 at 11:23:53AM +0000, Nick Clifton wrote:
>>>Hi Federico,
>>>
>>>>When I compile my code I get this message:
>>>>
>>>>ld: internal error: addend should be zero for R_LM32_16_GOT
>>>>
>>>>Then the compilation complete without errors (O_O)
>>>>(like if that error is not an error but a warning)
>>>
>>>This is a bug.  Either the code being linked is broken somehow, possibly
>>>due to a compiler or assembler error, and so the link should not have
>>>succeeded.  Or else the error message is actually a warning about behaviour
>>>that the programmer (of the linker) was not expecting, and so the linker
>>>might not have behaved correctly.
>>>
>>>A simple testcase to reproduce the problem would certainly be helpful for
>>>whomever does investigate this problem.
>>>
>>>
>>>>I do not understand what does this mean, and I cannot find information on
>>>>the web. Any hint?
>>>
>>>Well the error message comes from the lm32_elf_relocate_section function in the
>>>bfd/elf32-lm32.c source file, where it is processing the R_LM32_16_GOT reloc.
>>>
>>>Exactly what this relocation is supposed to do and why its addend should be zero
>>>I do not know.  It is presumably specified by the ABI for the LM32 architecture,
>>>but I could not find a copy of this document on the web. :-(
>>>
>>>
>>>>If this is not the right place, can you redirect me to the
>>>>right place?
>>>
>>>Probably the best person to ask would be the maintainer for the LM32 code -
>>>Jon Beniston.  I have added him to the CC list of this email.
>>>
>>>Cheers
>>>Nick



More information about the Binutils mailing list