Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 May 2017 14:59:18 -0700
From:      Mark Millard <markmi@dsl-only.net>
To:        Dimitry Andric <dim@FreeBSD.org>
Cc:        Roman Divacky <rdivacky@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   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)
Message-ID:  <AA9DF5DF-37D6-4E41-A5EF-D93B9F17D0F9@dsl-only.net>
In-Reply-To: <408D3509-3D62-4413-986B-6C1171FB6138@dsl-only.net>
References:  <bug-26519-7604@http.bugs.llvm.org/> <bug-26519-7604-UhFFHDCAay@http.bugs.llvm.org/> <0103401A-CEEA-4992-A45E-E60EA151119B@dsl-only.net> <893ECA11-7C80-4D24-A496-92ADC7978A07@FreeBSD.org> <408D3509-3D62-4413-986B-6C1171FB6138@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
[Top post of question with older material
 listed after for reference.]

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

(For both powerpc64 and powerpc handling
thrown C++ exceptions still needs work
but the above does make the rest of buildworld
operational for TARGET_ARCH=3Dpowerpc --as far
as my basic testing goes anyway.)

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

On 2017-May-17, at 3:22 PM, Mark Millard <markmi@dsl-only.net> wrote:

I got a notice this morning of the latest fix for
covering the TARGET_ARCH=3Dpowerpc stack-handling issues
for llvm bugzilla 26519:

> Comment # 33 on bug 26519 from Krzysztof Parzyszek
> The fix has been committed in master in r303257.
>=20
> I opened PR33070 to request merging it into 4.0.1.
>=20
> You are receiving this mail because:
> 	=E2=80=A2 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=3Dpowerpc vs. TARGET_ARCH=3Dpowerpc64 :

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=3Dpowerpc64 is:

# svnlite diff /usr/src/contrib/llvm/tools/
Index: /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- /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 =3D GotRel =3D R_PPC64_GLOB_DAT;
+  GotRel =3D R_PPC64_GLOB_DAT;
+  PltRel =3D R_PPC64_JMP_SLOT;
  RelativeRel =3D R_PPC64_RELATIVE;
  GotEntrySize =3D 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.

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AA9DF5DF-37D6-4E41-A5EF-D93B9F17D0F9>