This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See crosstool-NG for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
-------- 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |