[fpc-devel] Smart-linking on linux/x86-64
Sergei Gorelkin
gorelkin at nanoreflex.ru
Tue Jul 5 11:51:56 CEST 2022
05/07/2022 09:39, Sven Barth via fpc-devel wrote:
> Joost van der Sluis via fpc-devel <fpc-devel at lists.freepascal.org
> <mailto:fpc-devel at lists.freepascal.org>> schrieb am Di., 5. Juli 2022, 00:17:
>
>
> But my real issue is this: on Windows, using the internal linker, this
> procedure is also omitted *with* Dwarf debug-data. As you implied.
>
> The problem is, though, that the CFI-information (the FDE) is not
> omitted. This is 'solved' in the internal linker by replacing the
> address with 0. Gdb doesn't mind and I've adapted FpDebug so that it
> allows this too, but this is still invalid, imho.
>
> But as the FDE is written now, as 'one block', without any sections, I
> don't see how the linker could omit the corresponding FDE.
>
> Any suggestions? Is it possible to place every fde in it's own section
> to solve this?
>
>
> The problem is that *something* would need to reference the debug sections otherwise they are
> stripped as well. But as soon as they're referenced whatever code or data *they* reference is kept
> as well.
> One of the better solutions might be to write these references as weak symbols (on systems that
> support this) so at least the data/function isn't kept around.
> Or the section of the data/function would have to contain a reference to its corresponding debug
> entry so that it is kept around as long as the function/data is kept around...
> How does GCC do this?
>
As far as I had studied this issue, ld essentially "decompiles" the monolithic FDE's from object
files into internal representation, and then "compiles" it back, omitting information for the code
that won't go into executable due to smartlinking. It also optimizes for size by using 8- and 16-bit
offsets instead of 32-bit ones when possible.
Regards,
Sergei
More information about the fpc-devel
mailing list