Re: [Patches] SWI relocation error building EGLIBC for ARM Cortex-A8

["P. J. McDermott" <pjm@xxxxxxx>]

I seem to have figured out at least this error (see below). :)

On 04/21/2012 07:06 PM, Carlos O'Donell wrote:
> Sorry for the circular responses :-)
> 
> A couple of comments:
> 
> * Don't hack unistd.h, that's a bad idea.
> 
> * Use older kernel headers.
> 
> Then try again.

For now, I can write a patch for Linux-libre to not undefine
"__NR_syscall".  As a better/long-term solution though, I intend to file
a bug report with GLIBC and/or Linux (see below).

> I don't see that an undefined __NR_syscall has anything to do with your problem.

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 Linux's undefinition of (and GLIBC/EGLIBC's use of)
"__NR_syscall" is indeed the issue.  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.

I'm now getting the following linker error:

  arm-cortex_a8-linux-gnueabi-gcc   -nostdlib -nostartfiles -r -o <build
  >/elf/librtld.map.o '-Wl,-(' <build>/elf/dl-allobjs.os <build>/libc_pi
  c.a -lgcc '-Wl,-)' -Wl,-Map,<build>/elf/librtld.mapT
  <build>/libc_pic.a(init-first.os):(.data+0x0): multiple definition of
  `__libc_multiple_libcs'
  <build>/elf/dl-allobjs.os:(.bss+0x9c): first defined here
  collect2: ld returned 1 exit status

A Web search suggests that this may be due to my disabling of the SSP.
I'll try different configurations of EGLIBC, but in the meantime any
advice or hints would be appreciated.

> If you don't have the time to invest in fixing the issue you will need
> to rely on a stable and tested setup e.g. cross-tools. What you're
> trying to do isn't trivial and often broken or not well documented.
> 
> Cheers,
> Carlos.

Thanks,
P. J.
_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches