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] |
Thanks for the information. I'll try the newer versions of gcc and binutils. I doubt we will be able to move from glibc to eglibc. Keeping with a generic toolchain that produces binaries for both CPU's I think is going to be a hard requirement. I am almost debating patching gcc so when the generic "powerpc" CPU is specified, lwsync is disabled (like it is in rs6000.h, but no other file). On Sat, Aug 10, 2013 at 5:21 AM, Titus von Boxberg <titus@v9g.de> wrote: > -------- 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] |