5 ms·

Rappel: A REPL for x86, amd64, and armv7

150 points by gbarboza 11y ago

icholy 11y ago
I was looking for something exactly like this a few months back.
osandov 11y ago
Cool! I did something very similar to this a couple of years back: https://github.com/osandov/asmase https://github.com/osandov/asmase. Instead of assembling to a file, I used the LLVM libraries to assemble in memory, then used ptrace to get a child process to point its instruction pointer at that machine code.
oso2k 11y ago
Cool. Like debug[0][1], but less functional? I could myself using this more if some of debug's features were implemented. [0] https://en.wikipedia.org/wiki/Debug_(command) https://en.wikipedia.org/wiki/Debug_(command) [1] http://help.fdos.org/en/hhstndrd/base/debug.htm http://help.fdos.org/en/hhstndrd/base/debug.htm
drudru11 11y ago
This is cool. In the old days... computers came with these things built into the ROM (BIOS, Firmware, etc.). They were mostly called a 'ROM Monitor' or just the 'Monitor'. I never knew why they were called that, but I would guess that it was probably a term DEC or IBM invented. On a Sun, NeXT, or Cisco box, you could hit a magic keyboard sequence (or send an RS-232 BREAK over the console) to get to the monitor. It was a very powerful thing to be able to interrupt the running OS, modify it, and then resume it. On the NeXT, you could even work with OS structures or sync the disks. The monitor typically had a disassembler and a simple single step debugger. Earlier microcomputers also had these, and were helpful, but less powerful. For example, the Apple ][ had a monitor, but later ROMs did not allow you to invoke it with a key sequence. On the later Suns and Power Macs, the monitor was implemented as a standard called Open Firmware. This was basically a standardized Forth acting as a Monitor. Device drivers could be embedded as a bytecode like sequence of Forth words for ethernet or display cards. That way, you could use newer devices even with old firmware and with any CPU. Very cool. I wish this functionality would come back.
- bogomipz 11y ago
  On the old Sun gear if you sent a break signal over serial you wold interrupt the OS sure and be at the ROM monitor but you couldn't "resume" the OS, you could boot back up to single user or run level 3 but all of your previous state would be gone of course. Is that was you are referring to? I don't remember a disassembler being available from the prom monitor I do remember there a FORTH(sp?) interpreter though. Could you elaborate?
  - farva 11y ago
    The OpenFirmware system used on old Macintosh and Sun machines used an extended FORTH for the bootstrapping and hardware management. FreeBSD's bootloader has a similar system as well.
  - drudru11 11y ago
    There was a command to resume the OS after a break. You just hit 'c' then enter. http://www.cisco.com/c/en/us/support/docs/field-notices/misc/fn-tsbreak.html http://www.cisco.com/c/en/us/support/docs/field-notices/misc...
- chflags 11y ago
  "This is cool." Not just cool, but useful. "UEFI" should have been a Forth-like REPL like Sun, FreeBSD, OLPC, etc. The output of rappel reminds me of an "assembly level debugger" I used for many years called "ald". Maybe I am just stupid, but when I'm writing assembly I like to verify the contents of registers as a program executes. From user.h: "Fuck computers, multiarch is bullshit." Agreed. I need something that compiles easily on NetFreeOpenBSD x86. Mo multiarch bullshit. Meanwhile I will stick with as, objcopy and ald.
- junke 11y ago
  I remember issuing "call -151" on an Apple IIe to enter the monitor. I was too young to understand how it worked, but I was using the examples from the manual to define fast-drawing code for shapes (defined with an existing language made of combinations of down, left, right, up etc. commands) that could be called from Basic.
zx2c4 11y ago
I like how it colorized which registers have changed due to the last instruction. Awesome!
nanofortnight 11y ago
Would love x64 support.
- ant6n 11y ago
  As opposed to AMD64?
  - nickpsecurity 11y ago
    Maybe the commenter prefers Intel's branding. More resell value that way.
  - nanofortnight 11y ago
    Misread that as ARM64!
zokier 11y ago
Would seem useful idea to restrict the print only changed registers and have a command to print all registers. Right now you can fit like 3-4 operations in 80x25 terminal window.
xvilka 11y ago
Same could be done using radare2 [1] tool in debug mode ("r2 -d") and using "dxa" command, to write an opcode using assembly language and execute it in place. Or even using simple C-like language (called regg [2]) to do the same. P.S. It's always better to try radare2 from git, since it's very actively developed. [1] http://rada.re http://rada.re [2] https://github.com/radare/radare2/tree/master/libr/egg https://github.com/radare/radare2/tree/master/libr/egg
tyilo 11y ago
A (probably) shittier version of this for OS X: https://github.com/Tyilo/asm_repl https://github.com/Tyilo/asm_repl (I'm the author of it)

150 points by gbarboza 11y ago

I was looking for something exactly like this a few months back.

Cool! I did something very similar to this a couple of years back: https://github.com/osandov/asmase https://github.com/osandov/asmase. Instead of assembling to a file, I used the LLVM libraries to assemble in memory, then used ptrace to get a child process to point its instruction pointer at that machine code.

oso2k 11y ago

Cool. Like debug[0][1], but less functional? I could myself using this more if some of debug's features were implemented. [0] https://en.wikipedia.org/wiki/Debug_(command) https://en.wikipedia.org/wiki/Debug_(command) [1] http://help.fdos.org/en/hhstndrd/base/debug.htm http://help.fdos.org/en/hhstndrd/base/debug.htm

drudru11 11y ago

This is cool. In the old days... computers came with these things built into the ROM (BIOS, Firmware, etc.). They were mostly called a 'ROM Monitor' or just the 'Monitor'. I never knew why they were called that, but I would guess that it was probably a term DEC or IBM invented. On a Sun, NeXT, or Cisco box, you could hit a magic keyboard sequence (or send an RS-232 BREAK over the console) to get to the monitor. It was a very powerful thing to be able to interrupt the running OS, modify it, and then resume it. On the NeXT, you could even work with OS structures or sync the disks. The monitor typically had a disassembler and a simple single step debugger. Earlier microcomputers also had these, and were helpful, but less powerful. For example, the Apple ][ had a monitor, but later ROMs did not allow you to invoke it with a key sequence. On the later Suns and Power Macs, the monitor was implemented as a standard called Open Firmware. This was basically a standardized Forth acting as a Monitor. Device drivers could be embedded as a bytecode like sequence of Forth words for ethernet or display cards. That way, you could use newer devices even with old firmware and with any CPU. Very cool. I wish this functionality would come back.

bogomipz 11y ago
On the old Sun gear if you sent a break signal over serial you wold interrupt the OS sure and be at the ROM monitor but you couldn't "resume" the OS, you could boot back up to single user or run level 3 but all of your previous state would be gone of course. Is that was you are referring to? I don't remember a disassembler being available from the prom monitor I do remember there a FORTH(sp?) interpreter though. Could you elaborate?
- farva 11y ago
  The OpenFirmware system used on old Macintosh and Sun machines used an extended FORTH for the bootstrapping and hardware management. FreeBSD's bootloader has a similar system as well.
- drudru11 11y ago
  There was a command to resume the OS after a break. You just hit 'c' then enter. http://www.cisco.com/c/en/us/support/docs/field-notices/misc/fn-tsbreak.html http://www.cisco.com/c/en/us/support/docs/field-notices/misc...
chflags 11y ago
"This is cool." Not just cool, but useful. "UEFI" should have been a Forth-like REPL like Sun, FreeBSD, OLPC, etc. The output of rappel reminds me of an "assembly level debugger" I used for many years called "ald". Maybe I am just stupid, but when I'm writing assembly I like to verify the contents of registers as a program executes. From user.h: "Fuck computers, multiarch is bullshit." Agreed. I need something that compiles easily on NetFreeOpenBSD x86. Mo multiarch bullshit. Meanwhile I will stick with as, objcopy and ald.
junke 11y ago
I remember issuing "call -151" on an Apple IIe to enter the monitor. I was too young to understand how it worked, but I was using the examples from the manual to define fast-drawing code for shapes (defined with an existing language made of combinations of down, left, right, up etc. commands) that could be called from Basic.

zx2c4 11y ago

I like how it colorized which registers have changed due to the last instruction. Awesome!

nanofortnight 11y ago

Would love x64 support.

ant6n 11y ago
As opposed to AMD64?
- nickpsecurity 11y ago
  Maybe the commenter prefers Intel's branding. More resell value that way.
- nanofortnight 11y ago
  Misread that as ARM64!

zokier 11y ago

Would seem useful idea to restrict the print only changed registers and have a command to print all registers. Right now you can fit like 3-4 operations in 80x25 terminal window.

xvilka 11y ago

Same could be done using radare2 [1] tool in debug mode ("r2 -d") and using "dxa" command, to write an opcode using assembly language and execute it in place. Or even using simple C-like language (called regg [2]) to do the same. P.S. It's always better to try radare2 from git, since it's very actively developed. [1] http://rada.re http://rada.re [2] https://github.com/radare/radare2/tree/master/libr/egg https://github.com/radare/radare2/tree/master/libr/egg

tyilo 11y ago

A (probably) shittier version of this for OS X: https://github.com/Tyilo/asm_repl https://github.com/Tyilo/asm_repl (I'm the author of it)