Git Product home page Git Product logo

processable's Introduction

Processable

A Javascript process emulator and visual inspector/debugger.

Prototype here

Alpha here

Bleeding edge here

What it is

This project has a similar motivation to Assemblance: to demystify the working of computers on the operating system, process, and instruction levels. Where assemblance focuses on relating instructions generated by a compiler to their corresponding source, this project aims to visualizes the state of the machine as a process executes, again relating higher-level programming concepts to their system-level implementation.

We would like in particular to visualize registers and the stack throughout program execution, updating an HTML markup of the system after the execution of each instruction. As a way to teach systems programming, instructors are often tasked with conducting elaborate program traces to convey what's happening "beneath the hood" to their students. Performing these traces by hand on a blackboard is exhausting, and becomes messier as addresses change contents and must be erased and written over. However, generating these one instruction at a time in a program like Powerpoint is still more tedious. We propose a browser application that can generate these traces automatically for an arbitrary program. Eventually we would also like to develop a way to represent memory sections as they exist in a linux process: including .text, .rodata, .data, .bss, the memory mapping section, and the heap.

What it isn't

While "visual debugging" is a phrase that describes more or less the interface, it does not aim to be the go-to debugger for someone working on a large project, as performance is not a primary concern, or even identical behavior to a particular machine. Instead, we wish to help understand the way programs are executed at the border between hardware and software.

This work is part of my senior thesis, advised by Bob Dondero, and will be under development from June 2017 until (at least) April 2018.

Timeline:

  • November
    • Interpreter:
      • Registers
      • byte-addressable Memory
      • read-only text section
      • operand parsing/execution of most popular instructions
    • View:
      • Set up node environment for React, build system with webpack
      • Component for viewing text section
      • Component for viewing Registers and toggling decoding
  • December
    • Interpreter:
      • Add support for flags, conditional instructions
      • Compose "assembler" module and support .data, .bss, and .rodata sections
      • Write tests for remaining mnemonics
        • (january note: Some of this moved into FixedInt module)
    • View:
      • Implement component for viewing the stack
        • with toggle-able decoding options
      • Add flags to view
      • Add breakpoint toggles and execution controls to view
  • January
    • Interpreter:
      • Compose and test module for representing Fixed-width Integers and emulating ALU behavior
      • Support external function calls for c standard library methods
      • Connect with compiler on server side to run compiled C code
        • (february note: might want to stay serverless)
      • Add support for the heap / brk()
        • (pushed to february/beyond)
    • View:
      • Host alpha version and begin to solicit feedback
      • Improve customizability of stack/text components
      • Design Heap component
        • (pushed to february/beyond)
    • Paper:
      • Begin writing research/related projects
      • Describe core functionality and implementation
  • February
    • Interpreter:
      • Investigate substituting different architectures, restructuring if necessary
      • (stretch) Create alternate version to support ARM assembly
    • View:
      • Iterate on visual design from early feedback
      • (stretch) Integrate DWARF information from compiled code (toggle between source and assembly)
      • (stretch) Tweak view for flexibility in subsituting architectures
    • Paper:
      • Evaluate investigation into multiple architecture support, conclude on viability / potential for future work
  • March
    • Interpreter:
      • Ensure very robust error handling
      • Test on large array of programs to uncover weaknesses, document and/or fix them
      • Conclude all substantive edits to assembly interpreter / vm
    • View:
      • Integrate feedback from early users, host and solicit feedback on first iteration
      • Perform walkthroughs with students and collect detailed experience reports
      • Add inline documentation where applicable, and compose separate about section
  • April
    • View:
      • Integrate feedback on first iteration, release documented beta version
    • Paper:
      • Document student expriences
      • Finish describing implementation details
      • Seek feedback on documentation from professors
      • Clearly delineate between promising and unpromising areas of future work

processable's People

Contributors

rmw2 avatar

Stargazers

avatar

Watchers

avatar avatar

processable's Issues

Support non-uniform stack byte groupings

Allow users to toggle decoding breaks at different addresses of the stack.

Probably do this by editing the stack component to maintain a list of break addresses, and group bytes based on successive intervals formed by the breaks. Clicking on a break address will remove that break, and clicking on an unbroken address will add it to the list.

Refactor redundant decodable "item" components

The stack, static sections, heap, and even register components all have very similar 'item' components, which consist of a group of bytes, represented by a FixedInt, that can be toggled between several different decodings. There are subtle differences in the presentation of each, but it would be nice if they could inherit from a common "DecodableItem" or something.

Refactor library to be able to call other library functions

Currently each library function calls SysV_arg() on its own, but this means that a library function can't call another library function without manipulating registers and pushing another return address onto the stack. Ideally, the FFI could be abstracted out into a single wrapper function so rather than

abs: () => {
  let val = SysV_arg(0);
  SysV_ret(ALU.abs(val));
}

We could instead have

// for example
abs: (val) => {
  return ALU.abs(val)
}
// ...
lib = (func, argc) => {
  let args = [];
  for (let i = 0; i < argc; i++)
    args.push(SysV_arg(i));
  let retval = func(...args);
  SysV_ret(retval);
}

And have a single wrapper function, lib(), which does the wrapping in the FFI. Each function would need to specify it's number of arguments, and variadic functions would be tricky.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.