llvm FreeBSD powerpc ABI target bug fix: Re: [Bug 26519] Clang 4.0.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result)

[Mark Millard]

On 2017-May-5, at 1:22 AM, Mark Millard <markmi at dsl-only.net> wrote:

> On 2017-May-5, at 12:45 AM, Mark Millard <markmi at dsl-only.net> wrote:
> 
>> On 2017-May-4, at 2:41 PM, Dimitry Andric <dim at FreeBSD.org> wrote:
>> 
>>> . . .
>>> Thanks for the notice.  I have merged the upstream fix into head in
>>> r317810, and I will MFC it after a few days.
>> 
>> I now have an old PowerMac running:
>> 
>> # uname -paKU
>> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT  r317820M  powerpc powerpc 1200030 1200030
>> 
>> where buildworld was via clang 4 (an amd64->powerpc
>> cross build). Even the classic tiny program that
>> previously showed C++ exception handling was broken
>> and would crash the program now works when
>> re-compiled and re-linked. Commands that were
>> previous broken now work.

I messed up and accidentally installed the
gcc 4.2.1 world that I had also built. This
is why C++ exceptions appeared to be working
for powerpc.

Both TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64
have C++ exceptions still messed up.


>> (But my testing is nearly minimal at this point.)
>> 
>> The kernel is from gcc421.
>> 
>> 
>> 
>> I did try booting a kernel built by system-clang 4
>> and it got to:
>> 
>> exec /sbin/init: error 13
>> 
>> and a later alignment exception at sf_buf_alloc+0x260
>> 
>> (Hand transcribed screen information.)
>> 
>> This is the same as the last time that I tried
>> such. The exception involved:
>> 
>> exec_map_first_page
>> kern_execve
>> sys_execve
>> start_init
>> fork_exit
>> fork_trampoline
>> 
>> 
>> 
>> For the gcc 4.2.1 based kernel boot I have
>> had  one odd fatal kernel trap (0x903a64a,
>> "unknown") where the lr showed 0x907f . It
>> reported being stopped at:
>> 
>> ffs_truncate+0x1080
>> 
>> It appears that "call doadump" worked but
>> I've not looked at what was put in
>> /var/crash/ .
> 
> If I leave the PowerMac idle running:
> 
> # uname -paKU
> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT  r317820M  powerpc powerpc 1200030 1200030
> 
> it eventually gets the same ffs_truncate-tied fatal
> kernel trap, with the same odd lr and the like.
> 
> So, while I cannot directly cause the problem
> at a specific time, the problem is repeatable.
> 
> I did not build the kernel with a so-called
> "red-zone" to work around any stack-operation
> ordering problems that might still be around.
> But I do not know that such is involved here.
> It may be a while before I manage to get that
> much of an analysis done.

The ffs_truncate issue is odd:

A) It was gcc 4.2.1 based for both kernel and world.
B) I built a gcc 4.2.1 based debug kernel and
   installed it but that does not get the problem.

I sam trying the gcc 4.2.1 debug kernel with the
system clang 4 world now and will later switch
to the gcc 4.2.1 non-debug kernel to see what
happens.

But being a pure gcc 4.2.1 environment originally
suggests that the ffs_truncate issue is not
clang-toolchain related.

===
Mark Millard
markmi at dsl-only.net