* [U-Boot] sparc and .udiv/.rem/.urem/.umul/etc... link errors
@ 2011-10-13 5:33 Mike Frysinger
2011-10-13 8:45 ` Daniel Hellstrom
0 siblings, 1 reply; 5+ messages in thread
From: Mike Frysinger @ 2011-10-13 5:33 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] sparc and .udiv/.rem/.urem/.umul/etc... link errors
2011-10-13 5:33 [U-Boot] sparc and .udiv/.rem/.urem/.umul/etc... link errors Mike Frysinger
@ 2011-10-13 8:45 ` Daniel Hellstrom
2011-10-13 15:44 ` Mike Frysinger
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Hellstrom @ 2011-10-13 8:45 UTC (permalink / raw)
To: u-boot
On 10/13/2011 07:33 AM, Mike Frysinger wrote:
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] sparc and .udiv/.rem/.urem/.umul/etc... link errors
2011-10-13 8:45 ` Daniel Hellstrom
@ 2011-10-13 15:44 ` Mike Frysinger
2011-10-19 9:05 ` Daniel Hellstrom
0 siblings, 1 reply; 5+ messages in thread
From: Mike Frysinger @ 2011-10-13 15:44 UTC (permalink / raw)
To: u-boot
On Thursday 13 October 2011 04:45:27 Daniel Hellstrom wrote:
> On 10/13/2011 07:33 AM, Mike Frysinger wrote:
> > 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
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] sparc and .udiv/.rem/.urem/.umul/etc... link errors
2011-10-13 15:44 ` Mike Frysinger
@ 2011-10-19 9:05 ` Daniel Hellstrom
2011-10-19 14:20 ` Mike Frysinger
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Hellstrom @ 2011-10-19 9:05 UTC (permalink / raw)
To: u-boot
On 10/13/2011 05:44 PM, Mike Frysinger wrote:
> On Thursday 13 October 2011 04:45:27 Daniel Hellstrom wrote:
>> On 10/13/2011 07:33 AM, Mike Frysinger wrote:
>>> 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
>
>> 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.
>
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] sparc and .udiv/.rem/.urem/.umul/etc... link errors
2011-10-19 9:05 ` Daniel Hellstrom
@ 2011-10-19 14:20 ` Mike Frysinger
0 siblings, 0 replies; 5+ messages in thread
From: Mike Frysinger @ 2011-10-19 14:20 UTC (permalink / raw)
To: u-boot
On Wednesday 19 October 2011 05:05:22 Daniel Hellstrom wrote:
> On 10/13/2011 05:44 PM, Mike Frysinger wrote:
> > On Thursday 13 October 2011 04:45:27 Daniel Hellstrom wrote:
> >> On 10/13/2011 07:33 AM, Mike Frysinger wrote:
> >>> 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
> >
> >> 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.
>
> 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?
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-10-19 14:20 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-13 5:33 [U-Boot] sparc and .udiv/.rem/.urem/.umul/etc... link errors Mike Frysinger
2011-10-13 8:45 ` Daniel Hellstrom
2011-10-13 15:44 ` Mike Frysinger
2011-10-19 9:05 ` Daniel Hellstrom
2011-10-19 14:20 ` Mike Frysinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox