Re: cross-compiling LM32 internal error while linking

[Federico Vaga <federico dot vaga at gmail dot com>]

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