Understanding relocation information
in [Win32 Kernel]
|
Prev: Please tell me do i have a Win32 API which captures capture WinXp DDK DbgPrint messeges
Next: Shutdown dialog window handle ?
From: Tim Roberts on 10 Mar 2010 01:46 AG <heyji2(a)gmail.com> wrote: > >Though according to your explanations, there is only one way (a simple >addition) to apply the relocations. But I gave seven different >relocation types: IMAGE_REL_I386_* >I assume you don't know how they should be interpreted? The only available function is addition (and that is a change from the old 16-bit OMF format, which also supported subtraction). The seven options merely change what is added. Further, most of them will not be generated by the typical compiler. Let's look at them one by one. * IMAGE_REL_I386_DIR32 0x0006 The target�s 32-bit VA. Here, you have a case like: puts( "string" ); The assembler code will contain a "call" instruction with a 0 address. The relocation directive will mention the name "_puts" -- that's the target -- and say that it should be added at the "call" instruction plus 1 byte. The linker adds the final virtual address of the "_puts" symbol into the call instruction. * IMAGE_REL_I386_DIR32NB 0x0007 The target�s 32-bit RVA. The RVA is the address of the symbol relative to the beginning of the executable. Not clear to me where that would be used. * IMAGE_REL_I386_SECTION 0x000A The 16-bit section index of the section that contains the target. This is used to support debugging information. That seems self-explanatory. Your code will never see this option. It will only be present in .debug data sections. * IMAGE_REL_I386_SECREL 0x000B The 32-bit offset of the target from the beginning of its section. This is used to support debugging information and static thread local storage. Again, this seems self-explanatory. Might be useful in some specialized static data table operations, but you wouldn't see this in C code. * IMAGE_REL_I386_TOKEN 0x000C The CLR token. I don't know what this is for, but presumably it's something to allow a connection to managed code. * IMAGE_REL_I386_SECREL7 0x000D A 7-bit offset from the base of the section that contains the target. A specialized version of the 0x000B code to save space for small sections. * IMAGE_REL_I386_REL32 0x0014 The 32-bit relative displacement to the target. This supports the x86 relative branch and call instructions. Again, this seems self-explanatory. In the "puts" case above, instead of adding the virtual address of the "_puts" symbol, it adds the difference between "_puts" and the byte address immediately following the patch. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: AG on 10 Mar 2010 04:46 On Mar 10, 1:38 am, "Pavel A." <pave...(a)12fastmail34.fm> wrote: > Have you looked at PE loader code of Wine, Reactos? Hi Pavel, No I haven't, and it was my next step. Now I know what source code to dig into. Thanks.
From: AG on 10 Mar 2010 17:30 On Mar 10, 10:46 am, AG <hey...(a)gmail.com> wrote: > On Mar 10, 1:38 am, "Pavel A." <pave...(a)12fastmail34.fm> wrote: > > > Have you looked at PE loader code of Wine, Reactos? Actually I looked into the loader of Wine, which is quite simple but only handle image files, and not COFF files (or I missed it?). I think it is normal since from my understanding, only linkers need to handle relocations infos in COFF files. I checked Reactos, and it sounds great. Alexandre.
From: AG on 10 Mar 2010 17:31
Thanks Tim, Its crystal clear now. On Mar 10, 7:46 am, Tim Roberts <t...(a)probo.com> wrote: > AG <hey...(a)gmail.com> wrote: > > >Though according to your explanations, there is only one way (a simple > >addition) to apply the relocations. But I gave seven different > >relocation types: IMAGE_REL_I386_* > >I assume you don't know how they should be interpreted? > > The only available function is addition (and that is a change from the old > 16-bit OMF format, which also supported subtraction). The seven options > merely change what is added. Further, most of them will not be generated > by the typical compiler. > > Let's look at them one by one. > > * IMAGE_REL_I386_DIR32 0x0006 The targets 32-bit VA. > > Here, you have a case like: > puts( "string" ); > > The assembler code will contain a "call" instruction with a 0 address. The > relocation directive will mention the name "_puts" -- that's the target -- > and say that it should be added at the "call" instruction plus 1 byte. The > linker adds the final virtual address of the "_puts" symbol into the call > instruction. > > * IMAGE_REL_I386_DIR32NB 0x0007 The targets 32-bit RVA. > > The RVA is the address of the symbol relative to the beginning of the > executable. Not clear to me where that would be used. > > * IMAGE_REL_I386_SECTION 0x000A The 16-bit section index of the > section that contains the target. This is used to support debugging > information. > > That seems self-explanatory. Your code will never see this option. It > will only be present in .debug data sections. > > * IMAGE_REL_I386_SECREL 0x000B The 32-bit offset of the target from the > beginning of its section. This is used to support debugging information and > static thread local storage. > > Again, this seems self-explanatory. Might be useful in some specialized > static data table operations, but you wouldn't see this in C code. > > * IMAGE_REL_I386_TOKEN 0x000C The CLR token. > > I don't know what this is for, but presumably it's something to allow a > connection to managed code. > > * IMAGE_REL_I386_SECREL7 0x000D A 7-bit offset from the base of the > section that contains the target. > > A specialized version of the 0x000B code to save space for small sections.. > > * IMAGE_REL_I386_REL32 0x0014 The 32-bit relative displacement to the > target. This supports the x86 relative branch and call instructions. > > Again, this seems self-explanatory. In the "puts" case above, instead of > adding the virtual address of the "_puts" symbol, it adds the difference > between "_puts" and the byte address immediately following the patch. > -- > Tim Roberts, t...(a)probo.com > Providenza & Boekelheide, Inc. |