Re: Porting to Darwin

Brian,
I hand patched the C++ files from patch you attached and applied them
to a fresh checkout from SVN.

Actually, I didn't apply all of your C++ changes. In particular, I
kept the makedeps/makedeps.cpp version. It has some changes that I
applied, in particular to get precompiled headers working with the
Linux build. I agree that it doesn't make sense to have two versions
of the same code. I'd actually forgotten about the version under
tools. If we are going to remove one (and I agree we should) I'd
prefer to remove the one under tools. In any case, I applied your
modification to my version, even though it won't affect the Win32
compile.

Although for me the changes to includeDB and the header files are not
necessary, I applied them anyway.

I can see two problems when I try recompile world.

1. With compilation turned on I get a compilation failure at certain
points - it seems to vary exactly which method is affected. I've
already got this one on my list of todos, but I haven't got round to
it yet. The brings up a StackTraceInspector on the compile all
process. This leads to the second problem.

2. With the 16-byte alignment patch in place I get an access violation
if I try to click on something in the stack trace. This is probably
because the primitive that generates the Activations for the stack
frames doesn't understand about the 16-byte alignment yet. Commenting
out the 16-byte alignment patch fixes this issue.

If I turn off recompilation (by setting -UseRecompilation in the
strongtalkrc file; this refers to generation of native code from
compiled bytecode, rather than recompilation of Smalltalk source into
bytecode), recompile world completes without a problem, even with the
16-byte alignment patch in place.

Regards, Steve

On Jul 1, 6:50 am, Brian de Alwis <[email protected]> wrote:
> Hi Steve.  I've attached my Darwin patches here.  I've rearranged your
> posting slightly to explain Darwin first.  I think that will help in
> interpreting my comments about the patches.
>
> > Pardon my ignorance, but I have no knowledge of the Darwin
> > environment. Is StatBuffer relevant to Darwin? Does Darwin have a libc
> > equivalent? If so, one option would be to create a DarwinStatBuffer,
> > which may or not subclass the existing StatBuffer, and just override
> > the offset and length accessors with appropriate values for Darwin.
>
> You can think of Darwin as a BSD Unix user space overlaid on top of
> the Mach microkernel.  From a development perspective, it looks like a
> Unix/POSIX world with a bunch of extra libraries, called frameworks,
> that provide windowing, inter-app communication, preferences,
> accelerated graphics, etc.  That's why the Darwin port was so easy: it
> leveraged the heavy lifting from the Linux port, with the help of
> gcc's -mstackrealign.
>
> So Darwin has stat/fstat and a 'struct stat', just like any other
> Unix.  It has a libc, though it's really called libSystem.dylib, but
> there's a symlink to libc.dylib too.  So the calling interface is the
> same, with the same structures, etc.  But the order of a structure's
> elements may be different, and that's true of other unices too.  So
> Darwin will likely need a StatBuffer and so will any other new OS.
>
> My concern with having a DarwinStatBuffer (and a NetBSDStatBuffer, and
> FreeBSDStatBuffer, ...) is that we suffer an explosion and start
> pushing environment details into the Smalltalk code.  But that's
> something that can be dealt with later.
>
> > > Unfortunately my Darwin-patched sources leads to a
> > > failed assertion when filing in code, such as your ANSI exceptions.
>
> > Which assertion fails? Is it an assertion in Smalltalk or an assertion
> > in the VM? Can you send me your patches?
>
> It's a VM assertion in Klass::local_lookup(symbolOop) at line 271:
>
>      assert(mixin()->is_mixin(), "mixin must exist");
>
> I've attached my patches here; the changes are in two parts, and are
> straightforward:
>
>   1. darwin independent: fixing minor issues to do with the build
> process
>      a) there are two copies of makedeps, in /makedeps and /tools/
> makedeps:
>         I removed /makedeps
>      b) some minor win32 build issues, and use /tools/makedeps
>      c) some additions to header files to get them to build
>   2. darwin related:
>      a) patched /tools/makedeps for Darwin/MacOSX
>      b) cp -r build.linux build.darwin; hack appropriately
>      c) cp vm/runtime/os_linux.cpp vm/runtime/os_darwin.cpp and hack
> appropriately
>      d) some Darwin-related #ifdefs to header files to get them to
> build
>
> You'll see in vm/prims/prim.cpp that I commented out the ebx stack
> checking -- this was causing compilation issues on Darwin.
>
> But there's nothing that jumps out at me as to why the Win32 VM is
> failing that assertion.
>
> > > But a VM built from a fresh set of sources works fine.  So I'm in the
> > > middle of figuring out what part of my patches causes the issue.  (I
> > > can't seem to figure out how to get VisualStudio to load the .pdb file
> > > for debugging symbols though.)
>
> > Strange about the symbols. Are you using the solution file under the
> > build.win32 directory?
>
> Yes.
>
> The patches follow.
>
> Brian.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---