Pelles C forum
Pelles C => General discussions => Topic started by: czerny on March 10, 2013, 03:02:03 PM
-
Hi,
I want to know, if the linker is linking libs as a whole or only thouse functions (obj-files) needed.
I made a simple test ppw.
I have 3 libraries:
liba.lib: One function Add() in one source file a.c.
libb.lib: One function Mul() in one source file b.c.
liba.lib: Two functions Add() and Mul() in one source file c.c.
and two executables:
libtst1.exe: Which uses only Add() and links against libc.lib
libtst2.exe: Which uses only Add() and links against liba.lib
Problem: The 2 executales have both the same size. I had expected size(libtst2) < size(libtst1).
czerny
-
Hi,
I want to know, if the linker is linking libs as a whole or only thouse functions (obj-files) needed.
I made a simple test ppw.
I have 3 libraries:
liba.lib: One function Add() in one source file a.c.
libb.lib: One function Mul() in one source file b.c.
liba.lib: Two functions Add() and Mul() in one source file c.c.
and two executables:
libtst1.exe: Which uses only Add() and links against libc.lib
libtst2.exe: Which uses only Add() and links against liba.lib
Problem: The 2 executales have both the same size. I had expected size(libtst2) < size(libtst1).
czerny
If your libs are comparitively small the exe's block sizing may land you up with the same file size. On big libraries, you will see the difference.
In any case Pelle's linker is not a "smart linker"... that is it doesn't pick functions out of objects the way some do. It works at the object level. That is the minimum it can link is one object.
This means that if you are building a library with (lets say) 150 functions, you really need them to be in 150 separate source files, so they compile into 150 separate objects. That way the linker appears smart, picking only the needed objects (thus functions) to add to the executable.
If you took that 150 function library and compiled them all from one source page you'd have only one object and every program that uses the library would have all 150 functions linked in, even if you're only calling 1 or 2 of them.
-
Use linker option to create map-file and examine that.
-
If your libs are comparitively small the exe's block sizing may land you up with the same file size. On big libraries, you will see the difference.
This might be the case. Thank you!
-
Use linker option to create map-file and examine that.
Thank you timovjl, that is a good example.
czerny
-
If your libs are comparitively small the exe's block sizing may land you up with the same file size. On big libraries, you will see the difference.
This might be the case. Thank you!
On my own system I have a large library, basically an accumulation of frequently used functions. There are several hundred functions in it. Trust me I know how much difference using separate sources for each function makes...
-
Microsoft C have compiler option -Gy to separate functions to different sections in same object file.
-Gy (Enable Function-Level Linking)
http://msdn.microsoft.com/en-us/library/xsa71f43(v=vs.90).aspx
PellesC is missing that feature.
-
Microsoft C have compiler option -Gy to separate functions to different sections in same object file.
-Gy (Enable Function-Level Linking)
http://msdn.microsoft.com/en-us/library/xsa71f43(v=vs.90).aspx (http://msdn.microsoft.com/en-us/library/xsa71f43(v=vs.90).aspx)
PellesC is missing that feature.
Yep ... handy feature...
I guess Czerny can't hear me ....
-
Hi CommonTater,
In any case Pelle's linker is not a "smart linker"... that is it doesn't pick functions out of objects the way some do. It works at the object level. That is the minimum it can link is one object.
This is the granularity problem. Each procedure should go to separate modules. MS Link operates same as Polink. It extracts all the procedures from an object file.
-
This is the granularity problem. Each procedure should go to separate modules. MS Link operates same as Polink. It extracts all the procedures from an object file.
Is it so ? I think polink picks just functions from same sections only (.text .data)?
That msvc -Gy option isn't perfect, it puts all data to same .data section.
-
This is the granularity problem. Each procedure should go to separate modules. MS Link operates same as Polink. It extracts all the procedures from an object file.
Is it so ? I think polink picks just functions from same sections only (.text .data)?
That msvc -Gy option isn't perfect, it puts all data to same .data section.
Actually Timo ... that is why my libraries are organized as they are... each function in it's own "module" (source page).
If you write a library with func1() func2() func3() func4() all on the same source page, POCC will put them into a single .obj file and POLIB includes them in the .lib as one piece. Later when POLINK goes to the library, to get func1() for your current project, it will link the entire object, also linking in the other three, which will become dormant code (i.e. Bloat) in the resulting executable.
On the other hand, if you create 4 separate source pages --thus having POCC create 4 separate objects-- the linker will pick only the needed function and not include the others.
So, although we are saying it in different ways, Vortex and I do appear to agree...
-
Yep ... handy feature...
I guess Czerny can't hear me ....
I hear every word, Tater! Always!
-
This is the granularity problem. Each procedure should go to separate modules. MS Link operates same as Polink. It extracts all the procedures from an object file.
This is not the full truth. Both MS link and Polink know how to handle COMDAT sections ( COMDATs are described in the MS COFF docs ). Actually, the MSVC "function level linking" feature ( and also the "string pooling" thing ) are implemented by making use of such sections. In short: with COMDATs, it's possible that the linker uses certain sections of a module only - the rest won't become part of the final binary.
-
This is the granularity problem. Each procedure should go to separate modules. MS Link operates same as Polink. It extracts all the procedures from an object file.
This is not the full truth. Both MS link and Polink know how to handle COMDAT sections ( COMDATs are described in the MS COFF docs ). Actually, the MSVC "function level linking" feature ( and also the "string pooling" thing ) are implemented by making use of such sections. In short: with COMDATs, it's possible that the linker uses certain sections of a module only - the rest won't become part of the final binary.
Trust me... POLINK is not simply a rename of LINK from MSVC++. They are two very different animals.
If you don't want to be linking a whole mess of dead code into your programs, you will divide your code into separate source modules before compiling.
-
Trust me... POLINK is not simply a rename of LINK from MSVC++. They are two very different animals.
I have to admit that my faith is "limited" - due to certain experiences.
If you don't want to be linking a whole mess of dead code into your programs, you will divide your code into separate source modules before compiling.
Well, the claim in my previous post wasn't based on guesses but on results of experiments with both MS link and Polink.
-
This is not the full truth. Both MS link and Polink know how to handle COMDAT sections ( COMDATs are described in the MS COFF docs ). Actually, the MSVC "function level linking" feature ( and also the "string pooling" thing ) are implemented by making use of such sections. In short: with COMDATs, it's possible that the linker uses certain sections of a module only - the rest won't become part of the final binary.
Would you please make a little example project using COMDAT sections?
-
Would you please make a little example project using COMDAT sections?
A "project" is attached. It's for the command line only ( MAKE.BAT ) - it will need PATHs adjustments before running!
It needs PellesC and MS VC ( I used the free VC++ 2003 Toolkit ).
MS VC is used to create an object module/library that contains COMDATs.
Polink is used to create the final binary, IOW: it knows how to handle objects containing COMDATs and extracts the one function that is needed [ func2() ] from the ONE object module in the library.
-
Hi Japheth,
If I am not wrong, Masm does not support COMDAT. ( same for Poasm )
Checking the JWasm manual, I see that it supports this feature : 3.21 Segment Attribute COMDAT
-
Would you please make a little example project using COMDAT sections?
A "project" is attached. It's for the command line only ( MAKE.BAT ) - it will need PATHs adjustments before running!
It needs PellesC and MS VC ( I used the free VC++ 2003 Toolkit ).
MS VC is used to create an object module/library that contains COMDATs.
Polink is used to create the final binary, IOW: it knows how to handle objects containing COMDATs and extracts the one function that is needed [ func2() ] from the ONE object module in the library.
You may be correct ... However, that means going outside Pelles' toolchain, which you cannot do (not easily, at least) from within POIDE... It would require command line builds.
So, while it might be true that POLINK can do this, it is equally true that PellesC cannot.
-
MicroSoft Visual C++ no more (since 2005) support that /Gf enable string pooling (.data)
only /GF enable read-only string pooling (.rdata).
So it's quite useless now.
-
Hi timovjl,
This is why probably Japheth used the VC++ 2003 toolkit.
-
I think that forcing everything into one source file isn't practical from a maintenance view.
Creating source files for groups of related functions seems much more strait forward to me.
Sure you would still end up with some functions that you don't need, but there is seldom a situation where you only need one function out of each group.
-
Hi timovjl,
This is why probably Japheth used the VC++ 2003 toolkit.
Does anyone know a working download link for this old toolkit?