Re: three things I stumbled onto while building xnu-792.17.14
Re: three things I stumbled onto while building xnu-792.17.14
- Subject: Re: three things I stumbled onto while building xnu-792.17.14
- From: <email@hidden>
- Date: Thu, 03 May 2007 07:20:57 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed 02 May 2007 23:01:58 -0500,
Terry Lambert <email@hidden> wrote:
>
> On May 2, 2007, at 6:59 PM, email@hidden wrote:
> > Hi,
> >
> > Stumbled onto three things while trying to build xnu. Let me
> > split them up; they really aren't related to one-another...
> >
> > ....
> >
> > I'm just curious. What would it take to fix xnu to be able to
use
> > gcc-4.0?
>
> Building the gcc-4.0 compatible sources. 8-).
well blow-me-down why didn't *I* think of that :p
> > This is the first error I hit:
> >
> > […]
> > /Users/scifi/Projects/xnu/xnu-
> > 792.17.14_huh/iokit/Kernel/IOWorkLoop.cpp: In member function
> > ‘virtual bool IOWorkLoop::init()’:
> > /Users/scifi/Projects/xnu/xnu-
> > 792.17.14_huh/iokit/Kernel/IOWorkLoop.cpp:79: error: converting
> > from `IOReturn (IOWorkLoop::*)(void*, void*, void*, void*)' to
> > `IOReturn (*)(OSObject*, void*, void*, void*, void*)' in a kext.
> > Use OSMemberFunctionCast() instead.
> > /Users/scifi/Projects/xnu/xnu-
> > 792.17.14_huh/iokit/Kernel/IOWorkLoop.cpp:93: warning: invalid
> > conversion from ‘void (*)(void*, wait_result_t)’ to ‘void
> > (*)(void*)’
> > /Users/scifi/Projects/xnu/xnu-
> > 792.17.14_huh/iokit/Kernel/IOWorkLoop.cpp:93: warning:
> > initializing argument 1 of ‘thread* IOCreateThread(void
(*)(void*),
> > void*)’
> > […]
>
> Download the xnu-792.18.15 (x86) sources instead of 792.17.14
(ppc);
> all these issues are fixed there by doing what the compiler is
telling
> you to do in the error message ("Use OSMemberFunctionCast()
instead.").
If this is Apple's official stance on this, then I will try it.
But later in your reply below you seem to contradict yourself here.
I will put the rest of my comments on this down there.
> > Could we use a -std= option or something similar to let gcc-4.0
> > handle IOWorkLoop.cpp line 79 as gcc-3.3 would have?
>
> No.
>
> > The reason I'm asking is that I'm very keen on wanting to try
> > testing optimisations only available with gcc-4.0 such as
> > - -ftree-vectorize (a very important one).
>
> You will likely be unhappy with this particular option, since
vector
> registers are not spilled in normal context switches in kernel
code
> (e.g. between the kernel thread and interrupt context). They are
> spilled for KEXT calls, but not for the kernel itself, so you
will be
> corrupting registers all over the place. This is supposed to be
> explicitly disabled when building a static binary (like the
kernel)
> because of this.
I understand this.
It goes without saying.
I'm hoping we can work on this.
It's one of those things I do: push the envelope.
If ppl _are_ working on this, then I hope this list would be the
proper place to rendezvous with them, and here I am saying I'm very
interested in helping.
Hey if no one pushes these concepts further, I feel they'll never
get done.
Although not exactly akin to PPC+Altivec, I've had some experience
with FreeBSD/x86 kernels, and they've been able to insert some
MMX/etc. optimisations down into their code. About time we try
raising G4/G5 to match that level.
If no one works on it, how will it ever get done.
So maybe I'm the lone wolf on this… I hope not…
> > A second issue with xnu is that it uses "echo -n" quite a lot in
> > the scripts -- this is not supported by the latest bash-3.2.x,
> > producing some very strange "No rule for" errors. This is
> > actually a very common problem with many many projects all
around
> > the world. Most scripts will perform a test (a) for whether
echo
> > needs the -n, or (b) does a \c need to be added to the string to
> > be echoed, to prevent the automatic linefeed. With xnu, I've
> > simply replaced all plain echo cmds with /bin/echo or coreutils
> > /usr/local/bin/echo both of which do support the -n.
>
> This is a bug in /bin/echo which I will unfortunately have to try
to
> get fixed, now that I know about it (i.e. the "-n" option is
_NOT_
> supposed to be supported). See:
>
>
<http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html>
>
> "On XSI-conformant systems, if the first operand is -n, it shall
be
> treated as a string, not an option."
>
> So this is supposed to not work the way you want it to.
Not "me" -- whoever wrote those scripts for your tarballs. ;)
Again I'm pushing the envelope since I'm purposely staying current
with bash, ncurses, auto* tools, coreutils, findutils, make,
iconv, etc. etc. etc. (take a gander at the xfree86-devel list for
the past couple weeks to see what we've fixed there).
Again I feel it doesn't seem to be getting done otherwise (Fink
and MacPorts are still rather back-level in many areas, let alone
what Apple provides … and I detest pkg-mgrs, the project ought to
be able to be built the normal documented ways, if not then we
need to fix it … plus the pkg-mgrs *always* strip-out my own
tweak settings e.g. CxFLAGS env-vars and such).
I'm only reporting what needs to be fixed.
I can only supply patches to the published source -- a long time ago
we would have been able to do "cvs diff" against the live repo.
btw for that matter I don't see xnu anywhere in MacPorts tree as a
svn branch, neither are the prerequisite components.
So I'll attempt to send the diffs via bug-reports but as I said I
feel we aren't "in the loop" for affecting what gets fixed very
much that way, so I use this maillist to shed light on the matter.
The other half of this can only be done by filing bug-reports that
request which components that need upgrading, that can't be done
with patches, only with simple requests (e.g. "please upgrade the
provided bash to 3.2.x" ;) ).
> The current build system assumes that you will use a Tiger (or
Darwin)
> system with the current tools installed in order to do the build.
> From your description of running into this, you appear to be
building
> on a Leopard seed, instead.
# uname -a
Darwin SciFiG5.homeip.net 8.9.0 Darwin Kernel Version 8.9.0: Thu
Feb 22 20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power
Macintosh powerpc PowerMac7,3 Darwin
As I mentioned before, I try to keep up-to-date with the various
open projects. This does not mean I have Leopard installed here!
btw I stated on this list in times past that I will never trust
the "leaked" dmg's being spread on-line. I can't afford a
$pay-for$ ADC account so I'm unable to help work on those
projects in an official manner. I can only afford to help with
what's free & open (*ahem*). (Someone here a while back said I
should submit a proposal to get a paid-for ADC account maybe from
a mentorship but he's not responded to my private reply.)
> The fix for this is to modify the four lines in MakeInc.def, the
one
> line in MakeInc.dir, and the one line in MakeInc.rule to use:
>
> printf "%s"
>
> instead of:
>
> echo -n
>
> ...you will need to quote the entire argument list to make it
into a
> single string.
oh yes that was the _third_ way some scripts deal with the matter,
I'd forgotten about that… but it introduces yet another dependency.
> NOTE: Building a PPC kernel from the Intel sources so that you
can use
> the newer gcc is a totally unsupported PPC configuration, so if
it
> blows up or gives you rabies, you're on your own.
Here's where the "help" I'm getting on this list is contradicted.
Earlier above you said I should get the Intel sources, but here
you say I'm on my own if I do. This is what I'd expect from M$,
not from Apple. If Apple truly wants to support gcc-4.0 in this
regard, why won't Apple "fix it" for _all_ machines it supports --
we are all having to re-invent the same wheel over & over & over
again when this issue comes up, and this is why I feel bug-reports
seem to go ignored. ~sigh~
> > A third issue is with using the latest GNU make-3.81+.
>
> If you are complaining about the "powerbook option deprecated"
> message, ignore them.
I have no idea what you're talking about here, really.
> Alternately, use Apple's "make" instead, or
> port Apple's patches forward using the GNU Make sources and the
Apple
> supplied copies of the GNU Make sources.
Apple's gnumake is based on GNU make-3.80 which is terribly old
now. 3.81 has tons of fixes and updates, and I am actually sync'd
with their cvs version 3.81.90+.
As I said last time, if you-all are interested in letting the GNU
make team know that the Objective-C patches for make are
important, then please send a comment to that savannah bug-report I
mentioned last time, that's where we are tracking this issue.
They are the ones needing convincin', and we need you-all to help
convince them. I've already done my bit there. Please & thanks.
> > Yeah I could file bug-reports with Apple but boy they must have
an
> > avalanche already. (and no I can't afford to $pay$ for
expediting
> > anything…)
>
> The MakeInc.* changes are benign, but unless there's outside
demand
> (e.g. you file a bug report), you're going to have to keep
building
> Tiger on Tiger, or do the patches by hand.
And as I keep re-iterating, the general feeling is that those
bug-reports seem to go ignored for-ever & ever… surely someone has
already reported these problems, they _have_ been in so many xnu
releases for years, but we aren't privvy to see whether it _has_
been reported already nor what the statuses are for previously
filed reports by others. So each separate person "who cares" will
end up filing his own report, re-inventing the wheel again &
again. I'm complaining about the bug-report "repo" itself --
Apple needs to open them up for public research like the many many
projects based on e.g. "bugzilla". I'm sorry but this IMO is a
public stain that makes some of us believe Apple really doesn't
want to support open source very well. So I use the maillists to
shed light on the issues we're having, taking them public rather
than keeping them hidden in Apple's bug-report system.
> -- Terry
Thank you for discussing this. It's not the end of it, tho,
not until the issues are actually resolved.
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.5
wkYEARECAAYFAkY507IACgkQZbt5KOxKrtSTEQCffMTnisKxKjxI0kuOi6Idqn/wtvcA
nj+QALorPc3KFsj6REMsbJ26eFh7
=IZWD
-----END PGP SIGNATURE-----
--
Click for home mortgage, fast & free, no lender fee, approval today
http://tagline.hushmail.com/fc/CAaCXv1KZF8ZagbohAB2zJQlVkXIbfBT/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden