From 4ccabcfc103d7fbf068c6b83199b179ad1a65774 Mon Sep 17 00:00:00 2001 From: Stan H Date: Mon, 19 Feb 2018 23:16:58 +0100 Subject: [PATCH] Update README.md --- README.md | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 1b32859..ea64397 100644 --- a/README.md +++ b/README.md @@ -1,32 +1,37 @@ -# lyn +# `lyn` + Aims to bring the functionalities of a proper linker to EA. +(My goal will be to progressively port different EA-outputting tools to object-outputting tools, as well as allowing `lyn` to output directly to binary, so that using EA will eventually become a non-requirement.) + What `lyn` does is it takes a variable number of [ELF object files](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format) plus a bunch of options, and outputs corresponding labeled EA code to stdout (I'll probably make it able to output to file at some point) See the [FEU Thread](http://feuniverse.us/t/ea-asm-tool-lyn-elf2ea-if-you-will/2986?u=stanh) for a detailed walkthrough and other goodies. ## Usage + ``` -lyn [-nolink/-linkabs/-linkall] [-longcalls] [-raw] [-printtemp] [-autohook/-nohook] +lyn [-[no]link] [-[no]longcalls] [-[no]temp] [-[no]hook] [-raw] ``` (parameters, including elf file references, can be arranged in any order) -- `-nolink`/`-linkabs`/`-linkall` defines linking policy. Behavior may conflict when other options are set (other options usually have priority). - - `-nolink` prevents any anticipated linking to occur (all relocations will be exposed to EA) - - `-linkabs` will only link absolute symbols (ie symbols that cannot simply be represented as labels using EA) - - `-linkall` will link everything it can (absolutes, relatives, locals...) (set by default) -- `-longcalls` will transform any direct BL call (and maybe later other calls/jumps) to a call to a "trampoline", where the target symbol will be represented as absolute. -- `-raw` will prevent any anticipated computation to occur, exposing the elves as is. -- `-printtemp` will expose temporary symbols (for now this only includes labels associated with trampolines) -- `-autohook` will allow automatic hooking into vanilla routines (see above for details). On by default (disable it with `-nohook` or `-raw`) +- `-[no]link` specifies whether anticipated linking is to occur (elves linking between themselves) (default is on) +- `-[no]longcalls` specifies whether lyn should transform any relative jump/reference to an absolute one (useful when linking code using `bl`s to symbols out of range) (default is off) +- `-[no]temp` specifies whether lyn should keep & print *all* local symbols (when off, only the ones needed for relocation are kept) (default is off) +- `-[no]hook` specifies whether automatic routine replacement hooks should be inserted (this happens when an object-relative symbol and an absolute symbol in two different elves have the same name, then lyn will output a "hook" to where the absolute symbol points to that will jump to the object-relative location) (default is on) ## Planned features - Bugfixes (always) -- Code cleanup (kinda want to have my mini `elf` library to be a bit more clean and such) +- A Complete rewrite that would imply: + - Decoupling the object interface with the event-gerenating part (and then put the object bit into a reusable library (to make writing other object-generating tools)) + - Decoupling the object interface with the elf-reading bit, allowing me to define other ways of reading objects. - Support for more relocations (such as `ARM` relocations (`lyn` currently only supports a handful of `thumb` & `data` ones)) - Allowing handling not only only read-only allocated sections (`.text`, `.rodata`, etc) but also writable allocated sections (`.data`, `.bss`, etc). Idk how that'd work with EA tho... -- Maybe support for other output formats? I'm thinking [`json-bpatch`](https://github.com/zahlman/json_bpatch) since zahl himself mentionned being interested, or maybe also the ability to write directly to target binary? (Some would say heresy, but maybe then we'll finally have a proper linker that is fit for our purposes?) +- Allowing other output formats: + - Object files (in which case `lyn`'s role would be to merge/simplify objects rather than "translating" them) + - I'm thinking [`json-bpatch`](https://github.com/zahlman/json_bpatch) since zahl himself mentionned being interested. + - Direct output to target binary, and allowing some kind of control over how to do that. -**As always, any question or bug report can also be done by contacting me through the [FEU Thread](http://feuniverse.us/t/ea-asm-tool-lyn-elf2ea-if-you-will/2986?u=stanh) or on the [FEU Discord](http://feuniverse.us/t/feu-discord-server/1480?u=stanh).** +**As always, any question or bug report can also be done by posting in the [FEU Thread](http://feuniverse.us/t/ea-asm-tool-lyn-elf2ea-if-you-will/2986?u=stanh) (or on the [FEU Discord](http://feuniverse.us/t/feu-discord-server/1480?u=stanh) ~~whenever I'll decide to come back over there~~).**