harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Berezhniuk (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-5504) [drlvm][port] Restructure DRLVM's sources to extract most of platform dependent code into portlib
Date Mon, 25 Feb 2008 23:33:55 GMT

     [ https://issues.apache.org/jira/browse/HARMONY-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Ilya Berezhniuk updated HARMONY-5504:

    Attachment: 0012-Implemented-universal-transfer-control-stubs-in-PORT-a-part-of-hythread-was-moved-to-PORT.txt

Adding '0011' and '0012' patches.
These patches move to the portlib a part of hythread functionality, register context conversion
from VM core, and significantly modifies a scheme of signals/exceptions processing.

The main change is the following.
Earlier signals/exceptions handlers pushed required arguments for C-language handlers to stack/registers,
and used transfer control stub to go to the C handler. This C handler also used transfer control
stub to go to the modified register context after signal/exception processing. The transfer
control stub used JIT context from the stack iterator for restoring processor registers.

This patch introduces universal transfer control stub which uses Registers structure for restoring
context. (The stubs are in portlib and written in assembler. It would be better to rewrite
them in encoder - now VM provides executable memory for encoding.)

Another one function introduced is a function for preparing register context for calling C
This function receives variable arguments number: C-handler address to be called, Registers
pointer and up to 6 C-handler arguments.
Initial register context is stored to the appropriate stack area, and registers are modified
to call C handler.
Address to return from C handler is set to small assembler stub which calls transfer control
stub with saved register context - so C handler returns to the interrupted code.
Additional useful feature is provided: when the first argument for C handler is the same Registers
pointer as fixed argument, then C handler receives an address of Registers structure saved
on the stack as a first argument. So all modifications made by C handler in these Registers
will take effect after returning from C handler.

> [drlvm][port] Restructure DRLVM's sources to extract most of platform dependent code
into portlib
> -------------------------------------------------------------------------------------------------
>                 Key: HARMONY-5504
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5504
>             Project: Harmony
>          Issue Type: Task
>          Components: DRLVM
>         Environment: All
>            Reporter: Gregory Shimansky
>            Assignee: Gregory Shimansky
>         Attachments: 0001-Added-standalone-crash-handler-header-and-basic-infr.patch,
0002-move-moved-LIL-files-from-PORT-to-VMCORE.txt, 0002-move-moved-LIL-files-from-PORT-to-VMCORE.txt,
0003-corrected-build-for-moved-LIL.txt, 0004-moved-register-context-structure-to-open.txt,
0005-move-moved-native_modules-from-VMCORE-to-PORT.txt, 0006-native_modules-are-adopted-for-using-in-PORT.txt,
0007-Added-frame-info-header-for-iteration-in-compiled-st.patch, 0008-VM-memory-barriers-was-moved-to-PORT-as-inline.txt,
0009-move-Renamed-apr_thread_ext.h-to-port_thread.h.txt, 0010-PORT-thread-basic-implementation.txt,
0010-PORT-thread-basic-implementation.txt, 0011-move-Moved-files-responsible-for-context-conversion-and-C-handler-args-preparation.txt,
> There is a code freeze, so I decided to create a working place for my patches for DLRVM's
port library in JIRA.
> The goal of this task is to separate DRLVM's platform dependent code from VM sources
into multiple subcategories of port library. Such platform dependent code is crash handler,
stack iteration, signals/exception handlers, modules tables, NCAI safe memory access and probably
some more stuff that I didn't identify yet.
> Such separation will define clear interfaces, possibly some components could be reused
by other projects.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message