linker

Hello everyone,


Here are two conflicting documents from MSDN. About whether linker will modify code generated by compiler. I quote both of them here.

Document (1) mentioned linker can not modify any code generated by compiler, but document (2) mentioned linker will replace address code generated by compiler during fixup process.

Which one is correct?

1.

http://blogs.msdn.com/oldnewthing/ar...21/673830.aspx

--------------------
But the linker can't rewrite the code generated by the compiler.
--------------------

2.

http://www.microsoft.com/msj/0797/hood0797.aspx

--------------------
Consider a call to a function named Foo in C++:


//...
Foo();
//...



The exact bytes emitted from a 32-bit C++ compiler will be this:


E8 00 00 00 00



The 0xE8 is the CALL instruction opcode. The next DWORD should contain the offset to the Foo function (relative to the CALL instruction). It's pretty clear that Foo probably isn't zero bytes away from the CALL instruction. Simply put, this code wouldn't work as expected if you were to execute it. The code is broken, and needs to be fixed up. In the above example, the linker needs to replace the DWORD following the CALL opcode with the correct address of Foo.
--------------------


thanks in advance,
George

I couldn't be bothered to read all the text in the pages you linked to, but I know how it works from experience.

The linker WILL change the code generated by the compiler when the compiler is producing function calls outside of the current compile unit [a compile unit is normally one .c/.cpp file], where the linker finds the referred function in a different object file (the result of a different compile unit being compiled). If it can't find the function, it will generate an error.

The loader, when doing "fixup" will also modify these entries, when linking in the DLL's that the executable is using, e.g. C runtime library or Kernel32.dll.

In the case of DLL's being loaded into the system, these will potentially need to be relocated too - as the default DLL address isn't always available in the system, and thus the DLL will have to be located at a different (virtual) address, and all the addresses within the DLL that refer to absolute (virtual) addresses within that DLL will have to be "fixed up".

So, yes, the linker will definitely change what the compiler generated.

--
Mats

Thanks Mats,


Your reply is great! My question is answered.

Quote:

---

Originally Posted by matsp

I couldn't be bothered to read all the text in the pages you linked to, but I know how it works from experience.

The linker WILL change the code generated by the compiler when the compiler is producing function calls outside of the current compile unit [a compile unit is normally one .c/.cpp file], where the linker finds the referred function in a different object file (the result of a different compile unit being compiled). If it can't find the function, it will generate an error.

The loader, when doing "fixup" will also modify these entries, when linking in the DLL's that the executable is using, e.g. C runtime library or Kernel32.dll.

In the case of DLL's being loaded into the system, these will potentially need to be relocated too - as the default DLL address isn't always available in the system, and thus the DLL will have to be located at a different (virtual) address, and all the addresses within the DLL that refer to absolute (virtual) addresses within that DLL will have to be "fixed up".

So, yes, the linker will definitely change what the compiler generated.

--
Mats

---

regards,
George

blogs.msdn.com contains personal opinions of various MS-associated people and does NOT constitute official documentation. In case of conflict, assume the core MSDN to be correct unless the article specifically mentions an error in the official docs.

Thanks CornedBee,

Quote:

---

Originally Posted by CornedBee

blogs.msdn.com contains personal opinions of various MS-associated people and does NOT constitute official documentation. In case of conflict,
assume the core MSDN to be correct unless the article specifically mentions an error in the official docs.

---

I agree. What is your comments and ideas on my original question?


regards,
George

I posted them in the other thread.

Thanks CornedBee,


Do you mean #12 of topic dllimport?

http://cboard.cprogramming.com/showt...219#post721219

If yes, I think you mean you agree with (2) in my original question. Right?

Quote:

---

Originally Posted by CornedBee

I posted them in the other thread.

---

regards,
George