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-4, at 2:41 PM, Dimitry Andric <dim at FreeBSD.org> wrote:

> On 4 May 2017, at 21:39, Mark Millard <markmi at dsl-only.net> wrote:
>> 
>> I just got a report of a fix for the FreeBSD
>> powerpc ABI's code generation in llvm. It should
>> fix a stack handling related problem that
>> currently makes clang (through 4) largely useless
>> for TARGET_ARCH=powerpc .
>> 
>> On 2017-May-4, at 12:26 PM, bugzilla-daemon at llvm.org wrote:
>> 
>>> Comment # 19 on bug 26519 from Krzysztof Parzyszek
>>> Committed a fix in r302183.
>>> 
>>> You are receiving this mail because:
>>> 	• You reported the bug.
>> 
>> This would also apply to:
>> 
>> powerpc-unknown-freebsd12.0
>> 
>> not just 11.0
>> 
>> Hopefully it is an easy merge into
>> clang 4.
> 
> 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/ .

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