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

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