Re: 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)

2017-05-25 Thread Mark Millard 

On 2017-May-25, at 4:31 PM, Dimitry Andric  wrote:

> On 25 May 2017, at 23:59, Mark Millard  wrote:
>> 
>> Is llvm bugzilla's latest 26519 fix going to make it
>> into release/11.1.0 ? This fixes the last known stack
>> handling ABI violation for targeting powerpc FreeBSD
>> (32-bit).
> 
> I just committed it in r318906.  It should make 11.1-RELEASE.  Would be
> nice if we can finally close PR 206990. :)

To my knowledge there are no more stack handling
problems and use of the update should provide
evidence that 206990 can be closed.



But it may be a while before I update to direct
use of something after head -r317820. . .

I've frozen at head -317820 while trying to get
evidence for a periodic powerpc kernel panic in
that version (kernel built with gcc 4.2.1, worlds
via both compilers). Small adjustments that change
the kernel memory layout a little tend to change
the behavior, usually meaning no obvious symptoms.
So updating to some other version likely just
hides the problem. Unfortunately it frequently
takes hours for the panic to occur and so a long
time to conclude the panic is not likely to
happen in any test that I have running.

It may be that I just will not identify anything
that points at anything fairly specific to fix
but I've not given up yet.


What I know of for powerpc's clang status
with the stack handling fixes in place is:

A) Handling thrown C++ exceptions crashes
   for code generated by clang. (powerpc64
   also has this property.)

B) A clang-based kernel fails to start
   /sbin/init and then gets a data
   alignment panic.

Past investigations relative to (A) suggest
multiple problems are around that contribute,
it is not just one simple problem. I've
not looked at (B) yet.

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



___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: 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)

2017-05-17 Thread Mark Millard 
I got a notice this morning of the latest fix for
covering the TARGET_ARCH=powerpc stack-handling issues
for llvm bugzilla 26519:

> Comment # 33 on bug 26519 from Krzysztof Parzyszek
> The fix has been committed in master in r303257.
> 
> I opened PR33070 to request merging it into 4.0.1.
> 
> You are receiving this mail because:
>   • You reported the bug.

I've been using a version of the patch for some time
and for buildworld it appears that with it powerpc
and powerpc64 have a similar status: the one known
area not working is handling of thrown C++ exceptions
--for example the required dwarf information is
incomplete so programs crash.

   (I have one powerpc64 patch in use that is not
   applied upstream or in FreeBSD that is essential
   for the powerpc64 status. See the later side
   notes for the tiny patch.)

For buildkernel there is a difference for
TARGET_ARCH=powerpc vs. TARGET_ARCH=powerpc64 :

A) powerpc46 works for building and running the
   kernel and world on the old G5 PowerMacs.

B) powerpc FreeBSD on the same machines fails at
   the /sbin/init attempt and then gets an
   alignment exception. (I've not tried a G4
   or G3 yet.)

As of yet I've no clue why (B) is an issue.


Side notes:


Note 0:

The patch I was given a fair time ago that
is required for TARGET_ARCH=powerpc64 is:

# svnlite diff /usr/src/contrib/llvm/tools/
Index: /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp
===
--- /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp  (revision 317820)
+++ /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp  (working copy)
@@ -1070,7 +1070,8 @@
 }
 
 PPC64TargetInfo::PPC64TargetInfo() {
-  PltRel = GotRel = R_PPC64_GLOB_DAT;
+  GotRel = R_PPC64_GLOB_DAT;
+  PltRel = R_PPC64_JMP_SLOT;
   RelativeRel = R_PPC64_RELATIVE;
   GotEntrySize = 8;

(Thanks to Roman Divacky.)


Note 1:

While a pure gcc 4.2.1 buildworld buildkernel with
a debug kernel is working for booting and using,
a production style kernel gets occasional panics
on the old G5 PowerMacs. (The powerpc64 builds
work fine on the same machines.) (I've not tried
any G4's or a G3 yet.)

It also appears that small changes in memory
layout details (from trying to get better
evidence) change the behavior/failure-mode/
details. I do not expect to find out what is
going on any time soon.

The same problems existed when buildworld was
via clang 4. A kernel from a clang buildkernel
does not get far enough for me to see what it
would do for the issue.

As this issue is more fundamental to general
operation it has been getting much of my
FreeBSD time.

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

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: 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)

2017-05-06 Thread Mark Millard 
[I'm top posting a find of another stack
handling failure example from the updated
compiler for TARGET_ARCH=powerpc .]

Bad news: Another code generation error, this
time demonstrated in compiling part of perl5. . .
(I tried to build a port that indirectly
tried build perl5 but perl5's miniperl crashes.)

/usr/obj/portswork/usr/ports/lang/perl5.24/work/perl-5.24.1/numeric.c

has Perl_cast_iv(NV f) for which clang double stores
two different things to one address [24(r1)]. Below
the => lines are the double store, the second
destroying the r30 value that was saved in the first:

Dump of assembler code for function Perl_cast_iv:
   0x0196a114 <+0>: mflrr0
   0x0196a118 <+4>: stw r0,4(r1)
   0x0196a11c <+8>: stwur1,-32(r1)
   0x0196a120 <+12>:stw r31,28(r1)
=>   0x0196a124 <+16>:  stw r30,24(r1)
   0x0196a128 <+20>:mr  r31,r1
   0x0196a12c <+24>:mfcrr12
=>   0x0196a130 <+28>:  stw r12,24(r31)

Note: r31 == r1 for that second "=>" line.

The return code sequence has a similar
problem: two loads from the same address
for what should be distinct values.

Note: r31 == r1 here too.

=>   0x0196a1bc <+168>: lwz r12,24(r31)
   0x0196a1c0 <+172>:   lwz r0,36(r1)
   0x0196a1c4 <+176>:   lwz r31,28(r1)
=>   0x0196a1c8 <+180>: lwz r30,24(r1)
   0x0196a1cc <+184>:   mtcrf   32,r12
   0x0196a1d0 <+188>:   addir1,r1,32
   0x0196a1d4 <+192>:   mtlrr0
   0x0196a1d8 <+196>:   blr

The Perl_cast_iv source code looks like:

IV
Perl_cast_iv(NV f)
{
  if (f < IV_MAX_P1)
return f < IV_MIN ? IV_MIN : (IV) f;
  if (f < UV_MAX_P1) {
#if CASTFLAGS & 2
/* For future flexibility allowing for sizeof(UV) >= sizeof(IV)  */
if (f < UV_MAX_P1_HALF)
  return (IV)(UV) f;
f -= UV_MAX_P1_HALF;
return (IV)(((UV) f) | (1 + (UV_MAX >> 1)));
#else
return (IV)(UV) f;
#endif
  }
  return f > 0 ? (IV)UV_MAX : 0 /* NaN */;
}


This sort of thing might explain the
occasional panic that names ffs_truncate
if there is some infrequently used
routine that messes up the stack.


On 2017-May-6, at 12:06 AM, Mark Millard  wrote:

> On 2017-May-5, at 10:13 PM, Mark Millard  wrote:
> 
> 
>> On 2017-May-5, at 6:11 PM, Mark Millard  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

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: 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)

2017-05-06 Thread Mark Millard 
On 2017-May-5, at 10:13 PM, Mark Millard  wrote:


> On 2017-May-5, at 6:11 PM, Mark Millard  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

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: 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)

2017-05-05 Thread Mark Millard 

On 2017-May-5, at 6:11 PM, Mark Millard  wrote:

> On 2017-May-5, at 1:22 AM, Mark Millard  wrote:
> 
>> On 2017-May-5, at 12:45 AM, Mark Millard  wrote:
>> 
>>> On 2017-May-4, at 2:41 PM, Dimitry Andric  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.
> 
> 
>>> . . .
>>> 
>>> 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.

I found a bad (old) kernel module in /boot/kernel/
and eliminating it appears to have removed the
ffs_truncate problem.

And even more good news:

buildworld buildkernel makes extensive use
of signals and its failure is how I discovered
the original stack handling problems for
powerpc (the ABI violations). I used to
have to patch in so-called "red zone" handling
to avoid the issue.

No more: a running a kernel that was built
without a "red zone" and running a world based
on clang now allows buildworld buildkernel to
complete just fine: no evidence of ABI
violations in the world code that is executed.


Going the other direction: I've conformed that
clang still generates C++ programs that can not
handle thrown exceptions. Both powerpc and
powerpc64 are this way.

The only other area with an issue that I know
of is the exec /sbin/init failure that prevents
using the clang based kernel for powerpc.

(This is based on the system binutils for
powerpc and devel/*binutils for powerpc64
instead of lld and such. lld has its own
problems for these targets.)

I already build and run powerpc64 kernels
built by clang. That has been true for a
while.

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

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: 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)

2017-05-05 Thread Mark Millard 
On 2017-May-5, at 12:45 AM, Mark Millard  wrote:

> On 2017-May-4, at 2:41 PM, Dimitry Andric  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

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: 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)

2017-05-05 Thread Mark Millard 
On 2017-May-4, at 2:41 PM, Dimitry Andric  wrote:

> On 4 May 2017, at 21:39, Mark Millard  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-dae...@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

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: 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)

2017-05-04 Thread Dimitry Andric 
On 4 May 2017, at 21:39, Mark Millard  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-dae...@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.

-Dimitry



signature.asc
Description: Message signed with OpenPGP