Re: lwsync used in generic ppc crosstool-NG

[Neil Gierman <crossgcc-list@roadrunn.com>]

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