On 22 Jan 2004 at 14:56, Peter N Lewis wrote:
At 10:14 PM -0800 21/1/04, Peter Norton wrote:
I'm new in GNU Pascal and wonder the exe size compiler produces. Three lines Hello World source was blowed up to the 349 KB (!) exe. Stripped down (with -s) the executable is still big - 247 KB. The same source compiled with VirtualPascal's compiler is 11 KB exe. 20 times smaller! Am I doing something wrong?
We have a similar issue under Mac OS X.
The issue exists on all GPC platforms.
[...]
I'm not sure if dead code stripping is something that the linker does on some platforms and not others, or whether it is on the agenda for improving. It's probably not really a GPC issue at all, but more a gcc backend linker issue.
I believe it is mainly a gpc issue although one cannot of course totally eliminate gnu binutils from the equation. The problem, as I understand it, is that the linker cannot discard unused routines, unless each routine is in self-contained object file. A lot of gcc libraries are of course arranged in this way - i.e., each contains a whole load of object files, each representing a function - so when the library is linked, the linker can discard the object file(s) representing the function(s) that is(are) not referenced at all. Seems that gcc programmers who write libraries are accustomed to coding in this way (perhaps enforced by the features of the linker).
With gpc, we don't (with for example the RTS (libgpc.a)) separate each routine into a separate source file like gcc programmers do. Furthermore, the routines in each gpc unit are each encompassed in one single object file. This means that, with every unit that is used, all the routines get linked into the program, because the linker cannot separate them. The same goes for the gpc runtime library (libgpc.a). So the smallest gpc program will be at least as big as the sum of the object files in libgpc.a (or something generally along those lines anyway).
I have discussed this with Frank sometime in the recent past, and IIRC, the sum of the discussion was that the most straightforward solution (other than doing things the gcc way) would be to find a way of separating each routine, on compilation, into its own object file. There seem to be some mechanisms within the compiler and binutils to assist in doing this - the switches: "-fdata-sections" and "-ffunction- sections" passed on to the compiler, and then objcopy with the switch "--only-section".
I gave this a go sometime last summer and was "somewhat" successful (meaning I managed to separate the routines, etc., but only produced programs that crashed). In the end, I gave up, due to lack of time and perhaps the necessary knowledge. If someone has the time to look into it, I can pass on to you the details of my unsuccessful attempts - basically a simple gpc program that converts object files from gpc units that had been compiled with "-ffunction-sections" into a gnu library archive, after separating the functions (basically a shell to "objcopy").
If there is any general interest, I can upload the program source (3 different permutations, each with varying degrees of failure when put to the test), and perhaps if all of us put our minds to it, we could come up with some sort of solution that could eventually be integrated into gpc itself.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/