re: lwsync used in generic ppc crosstool-NG

["Titus von Boxberg" <titus at v9g dot de>]

-------- Original Message --------
> From: "Neil Gierman" <crossgcc-list@roadrunn.com>
> Sent: Freitag, 9. August 2013 22:47
> To: crossgcc@sourceware.org
> Subject: lwsync used in generic ppc crosstool-NG
> 
> I am upgrading our toolchain from:
> 
> crosstool-NG 1.3.1
> binutils-2.17
> gcc-4.2.1
> 
> To:
> 
> crosstool-NG 1.18.0
> binutils-2.20.1
> gcc-4.4.6
> 
> Using the attached CT_NG config.
> 
> We create a generic PPC toolchain because we want a single toolchain
> to create binaries that will run on both an e300 and e500 CPU. We do
> realize that we will lose some efficiency but we are willing to deal
> with that.
> 
> The problem is that a test program crashes with Illegal instruction.
> Upon researching that, I found that the instruction "lwsync" is used
> and one of our CPU's (e500) does not support that instruction. That
> lwsync instruction is coming from libstdc++ (verified with "objdump -d
> -M ppc libstdc++.so|grep lwsync"). Our 4.2.1 based toolchain does not
> have any instances of lwsync in libstdc++. We have tried passing
> __NO_LWSYNC__ and _TARGET_NO_LWSYNC in the config, but libstdc++ still
> has lwsync in it. Is there a place I am missing to create a toolchain
> for generic PPC without any instances of lwsync? Additionally, on the
> 4.2.1 based toolchain, I don't have to pass "-M ppc" to objdump to
> resolve the instruction names, however on the 4.4.6 based toolchain I
> have to pass "-M ppc" otherwise I don't get the instruction names in
> the disassembler output. I don't know if this is another symptom of
> the same root cause. I do have "powerpc" in both the ARCH and CPU
> values of the CT-NG configuration.
> 
> I have tried to create a test program that exhibits the problem
> without company proprietary information but the simple test programs
> always run without issue, so the only information I can forward
> publicly is the use of objdump.

Neil,

I don't have specific advice:
I'm using (dedicated) toolchains for an e500v2 and an e300
(gcc 4.7.2, binutils 2.22, glibc 2.13 for e300, eglibc 2.13 for e500v2)

I only faintly remember the pain building an e500v2 toolchain with
tools as old as your "new" versions.
>From that memory I'd recommend
- use toolchains dedicated to each arch
- use gcc >= 4.7
- use at least binutils 2.22
- maybe try using eglibc (2.13) for the e500

I doubt that a unified e300+e500 toolchain can be reached without much 
pain.

HTH.
Regards,
Titus



--
For unsubscribe information see http://sourceware.org/lists.html#faq