GhidraSleighEditor makes developing and modifying Ghidra Sleigh processor modules much more enjoyable by providing a modern day context sensitive editor with syntax highlighting, navigation, context sensitive error notation, quick fixes, and more. The editor is built with the excellent XTEXT DSL framework within Eclipse.
The information provided in this document is effective as of Ghidra Sleigh Editor 1.0.0 and is subject to change with future releases.
1.0.2:
lzcount to grammar1.0.1:
define token definitions@if "!=" comparisonpopcount to grammar1.0.0:
GhidraSleighEditor is installed manually into Eclipse and should be installed by anyone interested in working with processor module sleigh specifications. The GhidraSleighEditor must be manually installed in Eclipse. In the future the extension may be installed automatically along with the GhidraDev Eclipse plugin when setting up Eclipse for Ghidra scripting and plugin development.
GhidraSleighEditor can be installed into an existing installation of Eclipse the same way most Eclipse plugins are installed. From Eclipse:
Help -> Install New Software...Add...Archive...<GhidraInstallDir>/Extensions/Eclipse/GhidraSleighEditor/OK (name field can be blank)Ghidra category (or Ghidra Sleigh Editor entry)NextNextFinishInstall anywayRestart NowThe Ghidra Sleigh Editor provides a variety of features one would expect in any modern IDE to make
viewing, modifying, debugging, and creating Sleigh processor specifications as painless as possible.
Once installed, any .sinc or .slaspec file that is edited will be brought up in the sleigh
editor.
The editor provides the following capabilities:
Keywords, Tokens, Sub-constructor names, Comments, Instruction Formats, Strings, Variables, and more
can be colorized to make the sliegh specification more readable. In the
Window -> Preferences -> Sleigh preferences panel, the color and font style can be changed for any
sleigh file tokens.
The structure of a sleigh file while fairly simple can lend itself to errors when using a straight text editor. The editor understands the syntax and all constructs of a sleigh file. Instead of waiting for the sleigh compiler to produce an error, many but not all syntax errors can be caught and displayed with a red error marker.
The editor validates the definition of variables including locals. Though legal in the sleigh
compiler, it has been found that not declaring local variables leads to errors that are not be
caught by the sleigh compiler. For example, assigning to a variable ro when the actual register
name is r0 may go unnoticed. All local variables must be defined with with the local keyword or
with an initial :size.
Warnings on duplicate names of tokens is marked in yellow. Complex matching patterns such as
'!=' '<' '>' are warnings as well. Using comparison matching operators can cause the generated
.sla file to be much larger than necessary. Comparison matching should really never be used on any
tokens that are bigger than a few bits as the number of match cases generated will be large. Their
use is unavoidable in some cases.
There are some artificial enforcements in the editor that, while valid sleigh syntax, cause the
syntax to be unparsable. Because the sleigh Domain Specific Language (DSL) is a context sensitive
grammer, as well as using define-like pre-processing expansion, the editor only allows define
$() variables at certain locations where a single token would reside. The most common flagged
error is embedding a connecting & in a define and then using it an a match pattern:
:MOV ax, bx is t1=1 $(BadDefine) {} is not allowed, and instead should be
:MOV ax, bx is t1=1 & $(GoodDefine) {}.
Some simple syntax errors can be fixed quickly with QuickFix suggestions. Pressing Crtl-1 on an
error will bring up available quick-fixes:
local or the :size form if the size can be detected.More quick-fixes may be added in the future. Please note quickfixes can be slow on large files such as the AARCH64.
There are many constructs in a sleigh file that, when hovered over, will display additional information. This is especially useful for tokens to get their size without having to navigate to the token field definition. More hovers will be added.
$(Defines) display all the possible defines for the name, since the actual define used can't be
known.If you have edited a sleigh processor specification in a regular text editor, you will appreciate the forward and backward navigation supported on various variable name use and their associated definition. Navigation is supported on sub-constructor names, field token names, registers, macros names, local variables, define names, and user define pcodeop's.
Navigate by pressing F3 on a variable, using the forward/backward navigation arrows, or my
favorite the <-* that will navigate back to the last edit location.
Instead of keyword searching, the editor provides a find all uses of a variable. Each found use is listed in a search window with the text of the line where it is used displayed. Each found location can also be navigated to by double clicking on the found reference.
Use the editor popup menu Find References action.
The name of variables can be very important, and instead of doing a search and replace on a string,
the editor can refactor a name and change all other uses of that name. The name is even changed in
other .sinc and .slaspec files.
Use the editor popup menu Rename Element action.
Sleigh files can get large and messy during development. Instead of paying much attention to format,
or trying to format by hand you can use the Source Format action. Common constructs are lined up,
for example the token definitions will find the longest token and line up all other tokens and their
definition. All sub-constructors of the same name will be lined up on the is keyword, the match
pattern, and the semantic definitions. All constructors is keywords will be generally lined up
based on the longest print peice for each constructor. Statements will also be indented
consistently. Multi-line attach definitions will have each entry lined up. Formatting can be
restricted to a selection of lines to stop formatting from entirely re-formatting carefully
formatted files. Additional formatting may be added in the future, and the formatter may become more
configurable in the future.
Use the editor popup menu Source -> Format action.`
GhidraSleighEditor can be uninstalled as follows from Eclipse:
Help -> About Eclipse
Eclipse -> About EclipseInstallation DetailsUninstall...FinishRestart NowGhidraSleighEditor can be upgraded the same way it was initially installed.
The GhidraSleighEditor is currently built from Eclipse and distributed with Ghidra manually.
Ideally we will use Gradle one day, but we aren't there yet. We do rely on gradle prepDev to
generate the Eclipse project and build GhidraSleighEditor's dependencies though, hence the
build.gradle file.
NOTE: Only "Eclipse IDE for Java and DSL Developers" has the ability to do the below instructions. The following instructions assume that you are using this version of Eclipse.
It is also suggested that you use the "Eclipse IDE for Java and DSL Developers" if you will use the GhidraSleighEditor. You can build the GhidraSleighEditor installation zip with the XTEXT runtime in the plugin. The XTEXT runtime was not included in the distribution build because it would have added 80Meg.
Importing GhidraSleighEditor Eclipse projects (they are deactivated by default):
settings.gradle that includes the GhidraSleighEditor project.gradle eclipse -PeclipseDSL to generate the GhidraSleighEditor Eclipse projects.File -> Import -> General -> Existing Projects into Workspace.Generating all Sleigh XTEXT generated files:
src -> ghidra.xtext.sleigh -> GenerateSleigh.mwe2ghidra/GhidraBuild/EclipsePlugins/SleighEditor/ghidra.xtext.sleigh.antlr-generator-3.2.0-patch.jarRunAs -> MWE2 Workflow
Try out the Sleigh Editor
Eclipse SleighEditor and chose RunAs -> Eclipse RuntimeFile -> NewJavaProject...
Ghidra/Processors/<X><X><X>/data/languages/<file>.sinc or <file>.slaspec.slaspec or .sinc file from the file browser on eclipseOptional: Changing version number (GhidraSleighEditor is versioned independently of Ghidra):
feature.xml in the GhidraSleighEditor Feature project.x.y.z.qualifier and save.category.xml in the GhidraSleighEditor Feature project.ghidra.xtext.sleigh.editor (x.y.z.qualifier), and click "Remove".ghidra.xtext.sleigh.editor, and click "Add Feature".ghidra.ghidradev (x.y.z.qualifer), click "OK", and save.Optional: Including the XTEXT runtime You can include the XTEXT runtime or redist module in the .zip file which will negate the need to have Eclipse with the DSL in the Eclipse into which the Eclipse Sleigh Editor is installed to run.
redist and add org.eclipse.xtext.redistCreating an installation zip file to install in Eclipse:
gradle prepDev to ensure GhidraSleighEditor's dependencies are up-to-date.File -> Export -> Plug-in Development -> Deployable plugins and fragmentsArchive file and choose a directory to save it to. Name it
GhidraSleighEditor-x.y.z.zip.