Hi.
Is it ever possible to remove unreferenced and thus unused functions during compilation (like GCC does) so that they don't waste place in resulting binary code in SDCC?
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Generally, the linker should ignore object files that provide only unused symbols. If you implement your potentially unused functions in separate .c files and link your binary (not by #include'ing the .c files into one compilation unit, but by using the linker) from the resulting .rel or .obj or .o files, unused files (and thus functions) should be ignored.
Reportedly, some linkers unconditionally include all object files given on the command line - so you may have to collect them into a library (.a or .lib) first and then link your main object file with the library to achieve the desired effect.
I have never used z80, so I cannot provide any details nor can I verify that these general approaches actually work with our z80 tools.
Hope that helps,
Raphael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
None from mentioned worked out.
Tested linking separate .rel as well as prepared .lib. In both cases resulting binary included all unused functions.
Any ideas yet?
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The linking work like this: All .rel files are put into the binary. From each .lib file only the modules that are used are put into the binary, but everything from such a module is put into the binary.
Example:
a.rel has symbol a, references symbol c
b.rel has symbol b, references symbol d
l.lib has been created from from c.rel and d.rel; in c.rel, there are symbols c, d, and e, in d.rel there are symbols f and g.
If these are linked together, the following symbols will end up in the binary:
a, b, c, d, e. The following will not be put into the binary: f, g.
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What's not being explicitly mentioned is that when you form your library you should have one function per file. The linker pulls out an entire file (proper name = module) when it forms the binary.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, this helps.
I had to write a tool which splits C source file into plenty of small files each one containing only one function. Then I separately compile each and put them into library. Guys, you make my life interesting!
But the question is: WHY the linker cannot use one object (function, array) from library? Provided it knows which symbol is requested during linking and the object has its clear boundaries in library...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When writing a program, only include objects in the source that are really used¹
When writing a library only put things together into a source file that will be always used together
For this workflow, the current solution works perfectly.
However, it seems, alternative workflows are becoming more common (judging from support for eliminating unused functions being a commonly requested feature in SDCC now).
Philipp
¹ Many compilers today even give a warning if they find an unused function/variable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Provided it knows which symbol is requested during linking and the object has its clear boundaries in library...
That's the problem.. there are no clear boundaries in the library between items in the same file. That's why it's necessary to split into files first. If you know this from the beginning, it's less a big deal. However I'm more used to making libraries out of z80 asm functions where separation into files turns out to be a good way to organize asm code. This is less natural for C code I think.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Philipp,
imagine you have a set of functions that generate all possible commands for some ASIC, for example display list commands, in a file named dlcommands.c. You may use 20% of them in real life. But dlcommands.c is a part of ASIC library which is shipped with it and it is hard to imagine that one will tailor it for every special case. That's exact my case.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi.
Is it ever possible to remove unreferenced and thus unused functions during compilation (like GCC does) so that they don't waste place in resulting binary code in SDCC?
Thank you.
Hi,
Generally, the linker should ignore object files that provide only unused symbols. If you implement your potentially unused functions in separate .c files and link your binary (not by #include'ing the .c files into one compilation unit, but by using the linker) from the resulting .rel or .obj or .o files, unused files (and thus functions) should be ignored.
Reportedly, some linkers unconditionally include all object files given on the command line - so you may have to collect them into a library (.a or .lib) first and then link your main object file with the library to achieve the desired effect.
I have never used z80, so I cannot provide any details nor can I verify that these general approaches actually work with our z80 tools.
Hope that helps,
Raphael
The Z80 linker needs a lib to only pull in used modukes.
Philipp
Hi,
None from mentioned worked out.
Tested linking separate .rel as well as prepared .lib. In both cases resulting binary included all unused functions.
Any ideas yet?
Thank you.
The linking work like this: All .rel files are put into the binary. From each .lib file only the modules that are used are put into the binary, but everything from such a module is put into the binary.
Example:
a.rel has symbol a, references symbol c
b.rel has symbol b, references symbol d
l.lib has been created from from c.rel and d.rel; in c.rel, there are symbols c, d, and e, in d.rel there are symbols f and g.
If these are linked together, the following symbols will end up in the binary:
a, b, c, d, e. The following will not be put into the binary: f, g.
Philipp
What's not being explicitly mentioned is that when you form your library you should have one function per file. The linker pulls out an entire file (proper name = module) when it forms the binary.
Thanks, this helps.
I had to write a tool which splits C source file into plenty of small files each one containing only one function. Then I separately compile each and put them into library. Guys, you make my life interesting!
But the question is: WHY the linker cannot use one object (function, array) from library? Provided it knows which symbol is requested during linking and the object has its clear boundaries in library...
Well, I guess a common workflow is:
For this workflow, the current solution works perfectly.
However, it seems, alternative workflows are becoming more common (judging from support for eliminating unused functions being a commonly requested feature in SDCC now).
Philipp
¹ Many compilers today even give a warning if they find an unused function/variable.
Because noone programmed it to do so (yet). This is not a design choice, but something noone got around to.
Last edit: Maarten Brock 2017-07-15
That's the problem.. there are no clear boundaries in the library between items in the same file. That's why it's necessary to split into files first. If you know this from the beginning, it's less a big deal. However I'm more used to making libraries out of z80 asm functions where separation into files turns out to be a good way to organize asm code. This is less natural for C code I think.
Philipp,
imagine you have a set of functions that generate all possible commands for some ASIC, for example display list commands, in a file named dlcommands.c. You may use 20% of them in real life. But dlcommands.c is a part of ASIC library which is shipped with it and it is hard to imagine that one will tailor it for every special case. That's exact my case.
Also see issue [feature-requests:#452]
Related
Feature Requests: #452
Last edit: Maarten Brock 2023-01-09