-1

I know that these are the hex instructions, but aren't they usually 4 Bytes long?

 f5:    e8 00 00 00 00  callq   0 <main+0xfa>

this is one example of such a line in the output I get when I run objdump --disassemble file.o

Michael Petch
  • 46,082
  • 8
  • 107
  • 198
Michel Ruge
  • 17
  • 3
  • it says it means `callq 0`. No, they are not usually 4 bytes long. – user253751 Nov 26 '20 at 17:38
  • 1
    @MichaelPetch Why do you recommend `-D` over `-d`? The former is just going to disassemble data sections into garbage while the latter omits them. – fuz Nov 26 '20 at 18:14
  • 2
    Disassemble with `objdump --disassemble -r` to disassemble and show you the relocation entries and you will understand better. The 00 00 00 00 is the displacement to the call target. but the 00 00 00 00 is a place holder that the linker will fill in when the object becomes part of an executable. You will see the relocation entry with -r and there will be one for this call instruction. The x86 has a variable length instruction encoding so not all instructions are the same length – Michael Petch Nov 26 '20 at 18:20
  • @fuz The `-D` vs `-d` is only a personal preference when I view it and I didn't recommend it over what they had, my main thrust was adding `-r` for the relocations. I actually missed that his `objdump` command was in the question but wasn't obvious since they didn't make it stand out. I have edited their question and amended my comment. My comment was all about the relocation entries. I have added the `-r` to the OPs command in my new comment. – Michael Petch Nov 26 '20 at 18:21
  • I prefer -D usually as well, but thanks to you sometimes now use -d but it is not all about code, .data, .bss, etc are also often relevant, where things are, when examining a binary. – old_timer Nov 26 '20 at 19:16
  • You can have instructions of any length between 1 and 11 in x86. Have a look at these different length [NOP examples](https://stackoverflow.com/a/36361832/485343) for inspiration. – rustyx Nov 26 '20 at 20:05
  • @old_timer if you want to also dump data sections, consider `-s` which gives a more useful hexdump for non-executable sections. – fuz Nov 26 '20 at 20:47
  • 1
    @rustyx 1–15 bytes, not 1–11 bytes. – fuz Nov 26 '20 at 20:48

1 Answers1

1

You're disassembling a program for a CISC processor (probably x86-64). Instructions are any size and don't have an alignment demand.

That instruction clearly pushes the current address onto the stack; although since this is a .o file, it could also be an external call that has to get the real address patched in by the linker.

Joshua
  • 40,822
  • 8
  • 72
  • 132
  • 2
    Note that RISC processors too can have variable length instructions. RISC-V and ARM are two examples. Instruction encoding alone does not qualify a processor as CISC, though I do find the entire RISC/CISC dichotomy pretty ridiculous. – fuz Nov 26 '20 at 17:51
  • @fuz: If you know a RISC processor with an odd instruction length I'd like to know about it. – Joshua Nov 26 '20 at 18:23
  • Well, I'm unaware of any supporting odd-sized instruction lengths, but ARM Thumb2 does support 2, 4, and 6 byte instructions (if you count `IT` as the prefix it is meant to be and decoded as). Is it forbidden by RISC law to make byte-sized instructions? – fuz Nov 26 '20 at 18:31
  • @fuz: I just use the existence of odd-sized instructions as a very fast rule of thumb for it must be a CISC processor due to having it never fail so far. – Joshua Nov 26 '20 at 18:32
  • 3
    CISC vs RISC is not really a reason here, it is simply a case of one instruction set works one way another works another. ARM was fixed for a long time then thumb came and so you had two instruction sets, which were fixed within those modes, then thumb2 made thumb variable length. The OP does appear to be confused about learning one fixed length one (perhaps mips which also has 2 and 4 byte instructions like arm) and assuming the rest of the world works the same way. – old_timer Nov 26 '20 at 19:18