Rappel: A REPL for x86, amd64, and armv7

by gbarboza • 10 years ago

150 19 10 years ago

icholy• 10 years ago

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

osandov• 10 years ago

Cool! I did something very similar to this a couple of years back: 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• 10 years 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)

[1] http://help.fdos.org/en/hhstndrd/base/debug.htm

drudru112• 10 years 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• 10 years 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• 10 years 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.

drudru112• 10 years 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...

chflags• 10 years 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• 10 years 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.

hiteshk_msft• 10 years ago

This sounds similar to kernel debugging- is that what you have in mind? Windows (the OS I'm most familiar with) has a couple different styles of kernel debugging, which allows you to introspect various levels of system state:

https://msdn.microsoft.com/en-us/library/windows/hardware/ff...

https://msdn.microsoft.com/en-us/library/windows/hardware/hh...

vidarh• 10 years ago

Monitors were also an integral feature of most "freezer" cartridges for the C64, like Action Replay and The Final Cartridge I/II/III (you could get monitors you'd load into RAM as well, but the freezer cartridges had lots of extra capabilities and of course the advantage of having the monitor in ROM). For a couple of years, until I got hold of Turbo Assembler (no relation to the Borland PC assembler), I wrote most of my assembler straight into memory using the Action Replay monitor.

zx2c4• 10 years ago

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

Awesome!

nanofortnight2• 10 years ago

Would love x64 support.

ant6n• 10 years ago

As opposed to AMD64?

nickpsecurity• 10 years ago

Maybe the commenter prefers Intel's branding. More resell value that way.

nanofortnight2• 10 years ago

Misread that as ARM64!

zokier• 10 years 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• 10 years 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

[2] https://github.com/radare/radare2/tree/master/libr/egg

tyilo• 10 years ago

A (probably) shittier version of this for OS X: https://github.com/Tyilo/asm_repl

(I'm the author of it)

Rappel: A REPL for x86, amd64, and armv7

Related Stories