lwsync used in generic ppc crosstool-NG

[Neil Gierman]

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.

[Titus von Boxberg]

-------- Original Message --------

Sent: Freitag, 9. August 2013 22:47
Subject: lwsync used in generic ppc crosstool-NG
crosstool-NG 1.3.1
binutils-2.17
gcc-4.2.1
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

[Neil Gierman]

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).

Post by Titus von Boxberg
-------- Original Message --------

Sent: Freitag, 9. August 2013 22:47
Subject: lwsync used in generic ppc crosstool-NG
crosstool-NG 1.3.1
binutils-2.17
gcc-4.2.1
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'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

[Bill Pringlemeir]

Post by Neil Gierman
I doubt we will be able to move from glibc to eglibc.

'eglibc' is a drop in replacement. It is no where near as painful as
'uCLibc' or other library switches. The code size is a little smaller
and 'eglibc' doesn't have every esoteric feature.

Do you have a reason not to investigate? It is a little different, but
as you are switching tools anyways, I think this impact would be
minimal. Changing a glibc version is most likely a bigger change
impact.

Fwiw,
Bill Pringlemeir.

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