sparc and .udiv/.rem/.urem/.umul/etc... link errors
it seems that these symbols are usually implemented in the C library on sparc systems, but under u-boot, we don't have that luxury. Linux itself simply imports the relevant asm files from glibc into their lib subdir. without these, building u-boot for sparc targets with sparc linux compilers fail. any desire to make this work ? or just continue to force everyone to install a dedicated sparc-elf compiler ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111013/0e3769e4/attachment.pgp
Quoted 7 lines · Mike Frysinger
it seems that these symbols are usually implemented in the C library on sparc systems, but under u-boot, we don't have that luxury. Linux itself simply imports the relevant asm files from glibc into their lib subdir. without these, building u-boot for sparc targets with sparc linux compilers fail. any desire to make this work ? or just continue to force everyone to install a dedicated sparc-elf compiler ?
-mike
The .udiv/.rem ... functions are implemented by libgcc, an suggested implementation is given in the SPARCv8 Appendix E. The functions are needed when compiling for SPARCv7 CPUs which doesn't have a hardware multiplier/divider instead they are implemented in software, SPARCv8 CPUs have multiplier/divider in hardware so .mul/.rem etc is not needed. One can switch between V7 or V8 compatible code by adding -mv8 (GCC 3.4.4 or earlier) or -mcpu=v8 (in newer GCC). Sparc-linux toolchains will generate ELF binaries for Linux, that is not what we want?
Daniel
Quoted 9 lines · On Thursday 13 October 2011 04:45:27 Daniel Hellstrom wrote:
Quoted 6 lines · Mike Frysinger
it seems that these symbols are usually implemented in the C library on sparc systems, but under u-boot, we don't have that luxury. Linux itself simply imports the relevant asm files from glibc into their lib subdir. without these, building u-boot for sparc targets with sparc linux compilers fail. any desire to make this work ? or just continue to force everyone to install a dedicated sparc-elf compiler ?
The .udiv/.rem ... functions are implemented by libgcc
that is target dependent
Quoted 2 lines
Sparc-linux toolchains will generate ELF binaries for Linux, that is not what we want?
the file format is fine, but the supplementary libgcc for sparc-linux targets does not include these symbols. it relies on the C library to provide them.
glibc sparc system:
$ readelf -s /lib/libc.so.6 | grep '[.]u' 1231: 000f41e0 20 FUNC GLOBAL DEFAULT 10 .urem@@GLIBC_2.0 1369: 000f41a0 12 FUNC GLOBAL DEFAULT 10 .udiv@@GLIBC_2.0 1557: 000f4160 20 FUNC GLOBAL DEFAULT 10 .umul@@GLIBC_2.0
and if you look at gcc's source tree in gcc/config/sparc/t-*, you'll see that these libgcc routines are included for elf and leon targets, but not linux.
so whenever i build u-boot using a sparc-linux-gnu cross-compiler, it fails to link due to missing these symbols. if i use sparc-elf, it links fine. -mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111013/471b387d/attachment.pgp
Quoted 22 lines · Mike Frysinger
Quoted 8 lines · On Thursday 13 October 2011 04:45:27 Daniel Hellstrom wrote:
Quoted 6 lines · Mike Frysinger
it seems that these symbols are usually implemented in the C library on sparc systems, but under u-boot, we don't have that luxury. Linux itself simply imports the relevant asm files from glibc into their lib subdir. without these, building u-boot for sparc targets with sparc linux compilers fail. any desire to make this work ? or just continue to force everyone to install a dedicated sparc-elf compiler ?
The .udiv/.rem ... functions are implemented by libgcc
that is target dependent
Quoted 2 lines
Sparc-linux toolchains will generate ELF binaries for Linux, that is not what we want?
the file format is fine, but the supplementary libgcc for sparc-linux targets does not include these symbols. it relies on the C library to provide them.
glibc sparc system:
$ readelf -s /lib/libc.so.6 | grep '[.]u' 1231: 000f41e0 20 FUNC GLOBAL DEFAULT 10 .urem@@GLIBC_2.0 1369: 000f41a0 12 FUNC GLOBAL DEFAULT 10 .udiv@@GLIBC_2.0 1557: 000f4160 20 FUNC GLOBAL DEFAULT 10 .umul@@GLIBC_2.0
Quoted 6 lines
and if you look at gcc's source tree in gcc/config/sparc/t-*, you'll see that these libgcc routines are included for elf and leon targets, but not linux.
so whenever i build u-boot using a sparc-linux-gnu cross-compiler, it fails to link due to missing these symbols. if i use sparc-elf, it links fine.
Ok I see. I'm not a GCC guru, but my sparc-linux- toolchain (built with crosstool-ng) has a libgcc.a in lib/gcc/sparc-leon-linux-gnu/4.4.2 which includes the .mul/.div functions. I guess that is not the sparc-linux target but sparc-leon-linux though. Could we use 'sparc-linux-gcc -print-libgcc-file-name' in u-boot?
Daniel
Quoted 36 lines · On Wednesday 19 October 2011 05:05:22 Daniel Hellstrom wrote:
Quoted 27 lines · Mike Frysinger
Quoted 9 lines · On Thursday 13 October 2011 04:45:27 Daniel Hellstrom wrote:
Quoted 6 lines · Mike Frysinger
it seems that these symbols are usually implemented in the C library on sparc systems, but under u-boot, we don't have that luxury. Linux itself simply imports the relevant asm files from glibc into their lib subdir. without these, building u-boot for sparc targets with sparc linux compilers fail. any desire to make this work ? or just continue to force everyone to install a dedicated sparc-elf compiler ?
The .udiv/.rem ... functions are implemented by libgcc
that is target dependent
Quoted 2 lines
Sparc-linux toolchains will generate ELF binaries for Linux, that is not what we want?
the file format is fine, but the supplementary libgcc for sparc-linux targets does not include these symbols. it relies on the C library to provide them.
glibc sparc system:
$ readelf -s /lib/libc.so.6 | grep '[.]u'1231: 000f41e0 20 FUNC GLOBAL DEFAULT 10 .urem@@GLIBC_2.0 1369: 000f41a0 12 FUNC GLOBAL DEFAULT 10 .udiv@@GLIBC_2.0 1557: 000f4160 20 FUNC GLOBAL DEFAULT 10 .umul@@GLIBC_2.0Quoted 7 lines
and if you look at gcc's source tree in gcc/config/sparc/t-*, you'll see that these libgcc routines are included for elf and leon targets, but not linux.
so whenever i build u-boot using a sparc-linux-gnu cross-compiler, it fails to link due to missing these symbols. if i use sparc-elf, it links fine.
Quoted 5 lines
Ok I see. I'm not a GCC guru, but my sparc-linux- toolchain (built with crosstool-ng) has a libgcc.a in
lib/gcc/sparc-leon-linux-gnu/4.4.2which includes the .mul/.div functions. I guess that is not the sparc-linux target but sparc-leon-linux though. Could we use 'sparc-linux-gcc -print-libgcc-file-name' in u-boot?
right, you got those funcs because you're targeting leon. -print-libgcc-name doesn't help when using sparc-linux-gcc as that just gets you the libgcc.a that's missing these symbols :). and that's already what the u-boot build system is doing (see $(PLATFORM_LIBGCC) in top level Makefile).
what i'm semi proposing is that we implement USE_PRIVATE_LIBGCC for sparc platforms. or at least import these symbols that sparc-linux gcc targets expect to be in the C library.
in either case it should be easy to do -- just copy the files from the kernel. -mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111019/c2ff662d/attachment.pgp