This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: SWI relocation error building ARM Cortex-A8 toolchain
- From: "P. J. McDermott" <pjm at nac dot net>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: libc-help at sourceware dot org
- Date: Sat, 21 Apr 2012 23:08:03 -0400
- Subject: Re: SWI relocation error building ARM Cortex-A8 toolchain
- References: <4F92181E.3080203@nac.net> <201204202257.03541.vapier@gentoo.org>
On 04/20/2012 10:57 PM, Mike Frysinger wrote:
> On Friday 20 April 2012 22:14:54 P. J. McDermott wrote:
>> When I try to build EGLIBC
>
> this is a glibc mailing list. we can't really speak about the eglibc build
> system. you should try asking on an eglibc mailing list.
I realize the build systems are different, but I figured an upstream
GLIBC list would have more people who are familiar with the codebase.
Either way, I followed your advice [1] and then at least figured out
this error.
Since "__NR_syscall" is undefined in Linux's ARM asm/unistd.h header,
the C preprocessor should leave the macro unchanged in the SWI
instruction in ports/sysdeps/unix/sysv/linux/arm/sysdep.h. Having
looked at the Architecture Reference Manual for ARMv7-A, I know that the
syntax for the SWI (now SVC) instruction is "SVC<c> #<imm8>". So an SWI
instruction with an operand of anything other than an immediate value
would be an error. I wondered if Binutils would report this error with
the (rather cryptic, IMO) "cannot represent SWI relocation" message. So
I tested my theory and was able to reproduce the message with a simple
test case:
$ printf '\tSWI #1\n' > swi.S
$ arm-cortex_a8-linux-gnueabi-as swi.S
$ printf '\tSWI __NR_syscall\n' > swi.S
$ arm-cortex_a8-linux-gnueabi-as swi.S
swi.S: Assembler messages:
swi.S:1: Error: cannot represent SWI relocation in this object file fo
rmat
It looks like the issue is indeed Linux's undefinition of (and
GLIBC/EGLIBC's use of) "__NR_syscall".
It turns out that when I got the versioned symbol errors last time, I
had simply forgotten to run `make clean`... So now, with the "#undef"
lines removed from asm/unistd.h, I'm able to get past the "SWI
relocation" error and get to the linking stage. However, I'm now
getting a linker error; as it is unrelated to this assembler error (as
far as I know), I'll start a new thread for it.
1: http://www.eglibc.org/archives/patches/msg01131.html