Date: Mon, 21 Oct 2013 07:44:56 -0500 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Aleksander <aleek@FreeBSD.org>, freebsd-hackers@freebsd.org Subject: Re: modyfing cross toolchain compilation Message-ID: <526521C8.2030003@freebsd.org> In-Reply-To: <CABkKHSYQ=xM3BcrY1yueuQhKtXTh8SWJZ=LNrk-mthUrrOeoWw@mail.gmail.com> References: <CABkKHSYQ=xM3BcrY1yueuQhKtXTh8SWJZ=LNrk-mthUrrOeoWw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/21/13 01:38, Aleksander wrote: > hello! > > Few days ago, when playing with linux-ppc, I have identified a bug with > PowerPC toolchain. It turns out that PowerPC e500 core is not compilant > with generic ppc ISA - it lacks of 'lwsync' instruction. This instruction > is used in libstdc++.so library, so I need to modify toolchain build > process by adding -me500v2 option, when building libraries. Can you tell > me how to do it, so I can test this potential soluton? > Which core is this? sync (and lwsync) are supposed to be supported on all PowerPC processors, since they are part of Book II and is *supposed* to be transparently interpreted as "sync" if not supported since the L field of the encoding was reserved previous to the introduction of lwsync. So I think your CPU is broken. It seems like GCC does have some hacks for this and may do the right thing via adding some #defines if you set CPUTYPE=8450 in make.conf, but it doesn't look like the relevant glue in config/rs6000 is hooked up for that at present. Without those, since the instruction is supposed to be valid, it will happily compile and assemble it. So an immediate solution is to just change the instruction in libstdc++ to "sync". Longer term, probably the Book-E kernel should trap lwsync illegal instruction faults and interpret them as "sync" (or do nothing, actually, since a trap is as good as a sync) on such broken cores. I doubt this is the last piece of code is userland or ports that assumes that Book-II instructions are valid. This keeps binary compat with compliant cores. We should also fix up GCC so it sets TARGET_E500 if the right CPUTYPE is set so that natively compiled executables don't hit the trap. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?526521C8.2030003>