Xorg/xfce4 failing on Dual Processor G4 PowerMac's BUT Single Processor G4 PowerMac works (same boot SSD)...

[Mark Millard]

If I grab sources from svn it will be the first time that I've done so. I'd probably make a separate SSD and leave my "as distributed" powerpc/GENERIC SSD alone (it has other uses). Overall it will be some time before I've a rebuilt context if I try it. (It is probably a good thing for me to do at this stage.)


The svn-src-stable-10/2014-September signal handling commit comments that I noticed from you this month are for

"Fix 32-bit signal handling on ppc64." (r261095)

and for

"Set the si_code appropriately for exception-caused signals" (powerpc/aim/trap.c) (MFC r269701)

ppc64 (G5) is working and ppc32 (G4) is not working as far as the processor context goes for what I'me been reporting on. Although it is the powerpc/GENERIC build used for both contexts, not a powerpc64/GENERIC64 build for the G5's. (All 10.1-PRERELEASE r270981 now.)

So I'm guessing that you are expecting the si_code update to be what fixes things. If so then more than just LLDB would care about the ucode=??? assignments that were added.



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

On Sep 6, 2014, at 5:21 PM, Justin Hibbits <chmeeedalf at gmail.com> wrote:

On Sat, 6 Sep 2014 17:05:45 -0700
Mark Millard <markmi at dsl-only.net> wrote:

> I finally asked myself "how many gdb's does FreeBSD have?". This lead
> me to building and using devel/gdb (/usr/local/bin/gdb). Experiments
> indicates /usr/local/bin/gdb works on Xorg on the G4's. (Xorg's build
> installs gcc47 and apparently needs a newer gdb to go with it.)
> 
> Thus I managed to get a little more information: /usr/local/bin/gdb
> reports for Xorg the likes of:
> 
> [Inferior 1 (process 1934) exited with code 026]

This is the smoking gun.  Exit code 026 == 22 (decimal), which just so
happens to be EINVAL, returned by sigreturn().  I finished committing
all my merges to stable/10, so you could try building an updated
kernel, and see that it fixes it.

- Justin