{"id":3269,"date":"2011-03-24T11:00:00","date_gmt":"2011-03-24T11:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/anatomy-of-a-net-assembly-methods\/"},"modified":"2016-07-28T10:50:21","modified_gmt":"2016-07-28T10:50:21","slug":"anatomy-of-a-net-assembly-methods","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/blogs\/anatomy-of-a-net-assembly-methods\/","title":{"rendered":"Anatomy of a .NET Assembly – Methods"},"content":{"rendered":"

Any close look at the method definitions in a .NET assembly has to start off with the method’s information in the metadata tables – the MethodDef<\/code>. So lets do that.<\/p>\n

MethodDef<\/code><\/h4>\n

The MethodDef<\/code> entry for the entrypoint method in my TinyAssembly example used in previous posts has the following bytes:<\/p>\n

D0 20 00 00 00 00 91 00 47 00 0A 00 01 00<\/pre>\n
 According to the CLR spec, the row is interpreted as follows: <\/p>\n
    \n
  1. D0 20 00 00<\/code>: RVA<\/strong>. The RVA of the method body within the assembly (0x20d0).<\/li>\n
  2. 00 00<\/code>: ImplFlags<\/strong>. Various flags indicating how the method is implemented. All-zeros indicate this is a pure-IL managed method.<\/li>\n
  3. 91 00<\/code>: Flags<\/strong>. In this example, these flags indicate this method is declared private static hidebysig<\/code>. <\/li>\n
  4. 47 00<\/code>: Name<\/strong>. offset into #Strings<\/code> heap (‘Main’).<\/li>\n
  5. 0A 00<\/code>: Signature<\/strong>. Offset into #Blob<\/code> heap containing the signature (return type & parameter types) of the method. I might look at signature encodings in a later post. In this example, the bytes at this offset indicate a method with no parameters and a void<\/code> return type.<\/li>\n
  6. 01 00<\/code>: ParamList<\/strong>. A RID to the ParamDef<\/code> table with information on the method’s parameters. As this method has no parameters, and there is no ParamDef<\/code> table in the assembly, this is essentially ignored.<\/li>\n<\/ol>\n
    You’ll notice there’s no reference to the owning TypeDef<\/code> within a MethodDef<\/code>. In an assembly, associations like this are one-way – in order to find which type owns a particular method, you have to scan the TypeDef<\/code> table until you find a type that includes the method in its method list.<\/p>\n
    Method bodies<\/h4>\n
    So, a MethodDef<\/code> describes the basic properties of a method – its name, signature, and implementation details. What about the actual body of a method?<\/p>\n
    Within the assembly, these are all located between the CLI header\/strong name hash and the CLR metadata, as you can see:<\/p>\n
      \"CLI%20Contents%20annotated.png\"<\/a>  <\/p>\n
    The RVA within a MethodDef<\/code> tells us where the method body can be found. In this case, the RVA is 0x20d0, so the method body comprises the following bytes: <\/p>\n
    2E 72 01 00 00 70 28 11 00 00 0A 2A<\/pre>\n
     How are these bytes interpreted? To start with, we have to understand a bit about CIL opcodes.<\/p>\n
    Instruction encoding<\/h4>\n
    CIL uses a variable-length instruction encoding; each opcode can be represented by 1 or 2 bytes, with all the commonly-used instructions using 1 byte. After the opcode are bytes representing the argument to that instruction, if there is one.<\/p>\n
    There are usually two versions of instructions that take an argument, a short version<\/em> and a long version<\/em>. For example, the ldarg<\/code> instruction (load argument) is a 2-byte instruction that takes a 2-byte argument with the argument number to be loaded. However, very few methods are going to have argument lists with more than about 10 arguments, so the ldarg.s<\/code> 1-byte instruction takes a single byte with the argument number. And, in fact, IL takes this a step further, as there are separate ldarg.0<\/code>, ldarg.1<\/code>, ldarg.2<\/code> and ldarg.3<\/code> instructions to load the first 4 method arguments in only 1 byte.<\/p>\n
    If we compare the 3 different instructions encodings, we can see what difference in bytes this can do: <\/p>\n