Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Porting VM to Linux x86 #11

Open
GoogleCodeExporter opened this issue Sep 8, 2015 · 8 comments
Open

Porting VM to Linux x86 #11

GoogleCodeExporter opened this issue Sep 8, 2015 · 8 comments

Comments

@GoogleCodeExporter
Copy link

The problematic areas are likely to be:
    - calling conventions/spaghetti stack support
    - memory management
    - thread management

Original issue reported on code.google.com by [email protected] on 22 Sep 2006 at 9:53

@GoogleCodeExporter
Copy link
Author

Original comment by [email protected] on 22 Sep 2006 at 10:12

  • Added labels: OpSys-Linux

@GoogleCodeExporter
Copy link
Author

As posted to the list, I am close to having base level support for linux. As to 
the
issues mentioned in the original comment, here are my initial approaches
- calling conventions: primitive calling conventions are no different from 
those for
the Windows version, since both caller and callee can agree on a common 
convention.
For DLLs the story is a little different. The Windows APIs all use stdcall, 
whereas
Linux libraries generally use cdecl. The DLL call support was assuming that all 
DLLs
were stdcall. To work around the issue and support both stdcall calls on 
Windows and
cdecl calls on Linux I wrapped the DLL calls with an extra synthetic stack 
frame to
ensure that the esp/ebp get set back to the original locations. So far this 
appears
to work under both Windows and Linux (I can run the image under Windows, use dev
tools as normal, save image, file out etc. all without noticeable problems, and 
I can
run the deterministic test under Linux). That said, I have concerns over NLRs 
since I
am not pushing a return address.
- memory management: simple malloc/free (actually valloc to give page aligned
allocations) As far as I am aware, there is no direct Linux equivalent of the 
Windows
Alloc/Commit/Reset/Free memory operations. Of course we could write our own, 
but that
seems quite a big job and valloc/free seem OK for now, with one exception. For
reasons that I don't quite follow the reservation of memory is disconnected 
from its
release (ie. reservation is performed by ReservedSpace, release is performed by
VirtualSpace). Since the initial allocation is split in two for old and new 
spaces
one of the virtual spaces is unable to free its memory. This was causing the VM 
to
crash on exit, after running the tests - since valloc didn't alloc the address, 
free
cannot free it and this results in a SIGSEGV fault. For now, I am keeping a 
register
of allocations and only freeing those that have been allocated. This could need
revising subsequently if the lower half of a reserved space is freed without the
upper half, as clib's free will free the lot.

When I include recompileWorld in the test under Linux the garbage collector 
blows up
with a "pointer reversal should have taken place" assertion failure. I haven't
debugged this yet.
- thread management: using the NPTL pthread library. The thread id's I have 
wrapped
in a Thread class which is private to os_linux.cpp (by which I mean that allow 
other
source files can see the Thread class, no operations are exposed outside of
os_linux.cpp). A similar approach is taken to Event (wrapping a condition 
variable, a
mutex and a flag) and DLL (wrapping a library handle).

My approach generally has been opportunistic - I have only implemented those
operations on os:: required to allow the tests in deteministicallyTestSystem to 
pass.
 Other methods are left as stubs.

Similarly, in the image, I have only replaced those DLL calls necessary to make 
the
tests pass. Since we have no mechanism currently for bootstrapping an image, I 
am
using a common image for both Windows and Linux. To make this work I have 
created 2
variants of the Platform class - Win32Platform and UnixPlatform - together with
related file classes as necessary. Platform then becomes an alias to the 
appropriate
class and the last step of the VM bootstrap code populates the Platform 
association
with the appropriate platfrom, the name for which is retrieved from a new 
method on os::.

Due to these changes, the revised VM will not work with existing images, nor 
will the
new image run on existing VMs.

For now, I have excluded recompile world from the system test in the image 
included
in the attachment. Once I have figured out what is causing GC to barf, I will 
post a
revision.

The attachment is based on prunedtree's GCC changes with a few bug fixes, and 
Dave
Raymer's Linux build files.

Original comment by [email protected] on 18 Jun 2007 at 8:17

Attachments:

@GoogleCodeExporter
Copy link
Author

I'm trying to download the attachment but everytime I get "disconnected by the 
server" at random byte counts.  This doesn't happen if I download from other 
Google 
Code places.
Is it possible to publish the code somewhere else?  Thanks

Original comment by [email protected] on 9 Jul 2007 at 4:31

@GoogleCodeExporter
Copy link
Author

[deleted comment]

1 similar comment
@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

mirror:
  http://www.sendspace.com/file/n2mbp8

Original comment by [email protected] on 5 Aug 2007 at 2:22

@GoogleCodeExporter
Copy link
Author

Hi

I am also trying to download this precious porting code, but to no avail. Would 
it be
possible to repost it please?

Original comment by [email protected] on 14 Sep 2007 at 11:53

@GoogleCodeExporter
Copy link
Author

I don't know why people are having problems with this file. I just managed to
download it without a hitch. In any case, I've uploaded the file to sendspace 
again.
It can be retrieved via the following url http://www.sendspace.com/file/q5f4d4

Original comment by [email protected] on 5 Oct 2007 at 9:07

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant