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 10:13 PM, Mark Millard <markmi at dsl-only.net> wrote:


> On 2017-May-5, at 6:11 PM, Mark Millard <markmi at dsl-only.net> wrote:
> 
>>>> . . .
>>>> 
>>>> 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:

It also happens when busy.

>>> # 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.
>>> 
>>> . . .
>> 
>> 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.
> 
> I found a bad (old) kernel module in /boot/kernel/
> and eliminating it appears to have removed the
> ffs_truncate problem.
> 
> . . .

For the ffs_truncate problem I spoke too
soon: It happened again, this time while
the old PowerMac was busy.

The detail numbers and such were again the
same.


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