disassembly

I've set up a hello world program just for testing my riscv32-unknown-elf toolchain, spike , pk etc. Though I managed to get the hello world printed using spike --isa=RV32 pk hello.elf , I found out that if I added the -d flag for debugging, I was given following instructions (a section of the whole): core 0: 0x0000000000001000 (0x7ffff297) auipc t0, 0x7ffff : core 0: 0x0000000000001004 (0x00028067) jr t0 : core 0: 0xffffffff80000000 (0x1b00006f) j pc + 0x1b0 : core 0: 0xffffffff800001b0 (0x00000093) li ra, 0 : core 0: 0xffffffff800001b4 (0x00000113) li sp, 0 : core 0: 0xffffffff800001b8

How can I see the disassembled version of the executable (eg. a.out) of a C++ program on Mac OSx? Tony Delroy It's not exactly what you're asking for, but g++ -S produces assembly from source code and can be expected to be more readable than a disassembled version. If you can't recompile with -S (e.g. no source code), then gdb lets you disassemble, as does objdump --disassemble . Depends what you've installed. See also: https://superuser.com/questions/206547/how-can-i-install-objdump-on-mac-os-x Brett Hale Look at otool . i.e., otool -tv a.out Edit: To add to Tony's answer, objdump also has

My first question here, hopefully I'm not doing it wrong. My problem is that I have a certain old DOS program which has quite much hacked the file format to the extreme to save space. (Yes, it's a demoscene prod for those who know.) Objdump doesn't want to help me with it; quick Googling yielded no real results for the problem and the manpage doesn't seem too generous in this regard either. There are others yes, like lida. However, for some reason I couldn't get lida to work; I believe there are alternatives. Anyone have any experience of disassembling DOS executables on Linux? Or should I

I have disassembled code produced by the compiler, and I see that it has produced the following sequence of instructions: mov eax, edx shr eax, 1Fh add eax, edx sar eax, 1 What is the purpose of this code? I know that sar eax, 1 divides by 2, but what does shr eax, 1Fh do? Does this mean that EAX will be either 0 or 1 if the left bit was either 0 or 1? This looks strange to me! Can someone explain it? The quick answer to your question—what is shr eax, 1Fh —is that it serves to isolate the uppermost bit of eax . It might be easier to understand if you convert the hexadecimal 1Fh to decimal 31 .

I've been trying to understand the purpose of the 0x40 REX opcode for ASM x64 instructions. Like for instance, in this function prologue from Kernel32.dll: As you see they use push rbx as: 40 53 push rbx But using just the 53h opcode (without the prefix) also produces the same result: According to this site , the layout for the REX prefix is as follows: So 40h opcode seems to be not doing anything. Can someone explain its purpose? Nathan Fellman the 04xh bytes (i.e. 040h , 041h ... 04fh ) are indeed REX bytes. Each bit in the lower nibble has a meaning, as you listed in your question. The

lea 0x0(%esi),%esi I believe it has no result and is simply filling space. Is this the case? Its a NOP. It adds the contents of %esi and 0x0, and puts the result in %esi. Somebody either has a clumsy code generator or needs to fill N bytes, where this instruction is the right size. LEA instructions execute quite fast (typically 1 clock), so this is a lot better than N nops. The x86 being as quirky as it is, has a variety of instructions that effectively don't do anything but fill differing numbers of bytes. You may find other useless instructions of different lengths. You tend to find

I'm in middle of rewriting my assembler. While at it I'm curious about implementing disassembly as well. I want to make it simple and compact, and there's concepts I can exploit while doing so. It is possible to determine rest of the x86 instruction encoding from opcode (maybe prefix bytes are required too, a bit). I know many people have written tables for doing it. I'm not interested about mnemonics but instruction encoding, because it is an actual hard problem there. For each opcode number I need to know: does this instruction contain modrm? how many immediate fields does this instruction

I have been playing with the dis library to disassemble some Python source code, but I see that this does not recurse into functions or classes: import dis source_py = "test.py" with open(source_py) as f_source: source_code = f_source.read() byte_code = compile(source_code, source_py, "exec") dis.dis(byte_code) All I see are entries such as: 54 456 LOAD_CONST 63 (<code object foo at 022C9458, file "test.py", line 54>) 459 MAKE_FUNCTION 0 462 STORE_NAME 20 (foo) If the source file had a function foo() , I could obviously add something like the following to the sourcefile: dis.dis(foo) I cannot