Re: [fpc-devel] Smart-linking on linux/x86-64

[Joost van der Sluis via fpc-devel]

Op 05-07-2022 om 23:45 schreef Sven Barth via fpc-devel:
Joost van der Sluis via fpc-devel > schrieb am Di., 5. Juli 2022, 
22:37:


I think many people would be glad if you'd solve the issue of smart 
linking with debug information when an external linker is used. :)


That's easy. See the attachment (Linux only). The results are similar as 
gcc produces. Apparently ld does not regard references in debug-sections 
as real references, and replaces them with 0-addresses. Just like our 
internal linker on Windows does.


I don't dare to push it, though. Because:

1: Someone disabled this because some older version of LD cannot handle 
it. Maybe some version we use still use on some targets/systems?


2: Someone disabled this because of some corner-case we now don't know 
of anymore.


Does anyone have some more information?

Regards,

Joostdiff --git a/compiler/options.pas b/compiler/options.pas
index 75d7f6f255..64022a722b 100644
--- a/compiler/options.pas
+++ b/compiler/options.pas
@@ -3870,7 +3870,7 @@ procedure TOption.checkoptionscompatibility;
 {$endif i8086_link_intern_debuginfo}
 
   if (paratargetdbg in [dbg_dwarf2,dbg_dwarf3]) and
- not(target_info.system in (systems_darwin+[system_i8086_msdos,system_i8086_embedded])) then
+ not(target_info.system in (systems_darwin+systems_linux+[system_i8086_msdos,system_i8086_embedded])) then
 begin
   { smartlink creation does not yet work with DWARF
 debug info on most targets, but it works in internal assembler }

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

[Joost van der Sluis via fpc-devel]

Op 05-07-2022 om 11:51 schreef Sergei Gorelkin via fpc-devel:

05/07/2022 09:39, Sven Barth via fpc-devel wrote:
Joost van der Sluis via fpc-devel > schrieb am Di., 5. Juli 2022, 
00:17:
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.


Indeed, that is also what I have seen. ld Adapts the cfi-contents. (It 
also removed some mistakes in fpc's implementation)


Regards,

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

[Christo Crause via fpc-devel]

On Tue, Jul 5, 2022 at 11:45 PM Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:

>
> I think many people would be glad if you'd solve the issue of smart
> linking with debug information when an external linker is used. :)
>
> Regards,
> Sven
>
>>
Indeed, a similar problem exists for AVR:
https://gitlab.com/freepascal.org/fpc/source/-/issues/39825
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

[Sergei Gorelkin via fpc-devel]

05/07/2022 09:39, Sven Barth via fpc-devel wrote:
Joost van der Sluis via fpc-devel > 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

[Sven Barth via fpc-devel]

Joost van der Sluis via fpc-devel  schrieb
am Di., 5. Juli 2022, 22:37:

>
>
>
> Op 05-07-2022 om 08:39 schreef Sven Barth via fpc-devel:
> > Joost van der Sluis via fpc-devel  > > schrieb am Di., 5. Juli 2022,
> > 00:17:
> > 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?
>
> Apperently GCC does the exact same thing as fpc does on Windows. Replace
> the addresses with 0, and mixup the function-names.
>
> (The link between the CFI and actual code consists of local labels. They
> do not reference the global labels/sections. I guess that is why the
> code is removed, as it's global label is not referenced)
>
> I can adapt fpc so that it does the same on Linux also. So I think I'll
> leave it this way.
>

I think many people would be glad if you'd solve the issue of smart linking
with debug information when an external linker is used. :)

Regards,
Sven

>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

[Joost van der Sluis via fpc-devel]

Op 05-07-2022 om 08:39 schreef Sven Barth via fpc-devel:
Joost van der Sluis via fpc-devel > schrieb am Di., 5. Juli 2022, 
00:17:

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?


Apperently GCC does the exact same thing as fpc does on Windows. Replace 
the addresses with 0, and mixup the function-names.


(The link between the CFI and actual code consists of local labels. They 
do not reference the global labels/sections. I guess that is why the 
code is removed, as it's global label is not referenced)


I can adapt fpc so that it does the same on Linux also. So I think I'll 
leave it this way.


Thanks for the help.

Joost.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

[Sven Barth via fpc-devel]

Joost van der Sluis via fpc-devel  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?

Regards,
Sven

>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

[Joost van der Sluis via fpc-devel]

Op 04-07-2022 om 23:37 schreef Sven Barth via fpc-devel:

Am 04.07.2022 um 19:52 schrieb Joost van der Sluis via fpc-devel:

Hi all,

I have a very small application, see below. One procedure is not 
called at all.


But when I compile with

ppcx64 -XX -CX testcfi.pp

The P$TESTCFI_$$_NEVERCALLES symbol is still in the executable.

On Windows (internal linker) this code is omitted from the executable, 
but not on Linux.


Does anyone know why?


I can't reproduce this with main. But considering that you named the 
test file “testcfi”: do you by chance play around with DWARF data? Cause 
DWARF doesn't support smartlinking on non-Windows, at least not in the 
way FPC generates it...


After your and Michael's response, I've tried it again and I can't 
reproduce it anymore either...


I'm still wondering what I did wrong.

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?


Regards,

Joost.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

[Sven Barth via fpc-devel]

Am 04.07.2022 um 19:52 schrieb Joost van der Sluis via fpc-devel:

Hi all,

I have a very small application, see below. One procedure is not 
called at all.


But when I compile with

ppcx64 -XX -CX testcfi.pp

The P$TESTCFI_$$_NEVERCALLES symbol is still in the executable.

On Windows (internal linker) this code is omitted from the executable, 
but not on Linux.


Does anyone know why?


I can't reproduce this with main. But considering that you named the 
test file “testcfi”: do you by chance play around with DWARF data? Cause 
DWARF doesn't support smartlinking on non-Windows, at least not in the 
way FPC generates it...


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

[Martin Frb via fpc-devel]

On 04/07/2022 21:11, Michael Van Canneyt via fpc-devel wrote:



On Mon, 4 Jul 2022, Joost van der Sluis via fpc-devel wrote:


Hi all,

I have a very small application, see below. One procedure is not 
called at all.


But when I compile with

ppcx64 -XX -CX testcfi.pp

The P$TESTCFI_$$_NEVERCALLES symbol is still in the executable.

On Windows (internal linker) this code is omitted from the 
executable, but not on Linux.


It's omitted here as well:


Not 100% on topic (sorry) but talking about symbols that are (or are 
not) included/excluded from the exe...


There are cases were (imho) too many symbols are omitted, and it has 
gotten worse from 3.2.3 to 3.3.1.


https://gitlab.com/freepascal.org/fpc/source/-/issues/39824
There may not be a variable of the class in question, but the class is 
created. Therefore it exists in the app, and could be needed by a debugger.


Yet while both 2.3.2 and 3.3.1 omit the info itself, an effort was made 
in 3.3.1 to clean up the $$vmt info too, imho that should be reverted, 
and the full info included.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Smart-linking on linux/x86-64

[Michael Van Canneyt via fpc-devel]

On Mon, 4 Jul 2022, Joost van der Sluis via fpc-devel wrote:


Hi all,

I have a very small application, see below. One procedure is not called at 
all.


But when I compile with

ppcx64 -XX -CX testcfi.pp

The P$TESTCFI_$$_NEVERCALLES symbol is still in the executable.

On Windows (internal linker) this code is omitted from the executable, but 
not on Linux.


It's omitted here as well:


objdump -t a | grep -i TESTCFI_

004010d0 g F .text  000e P$TESTCFI_$$_NOSTACKFRAME
00401080 g F .text  0047 P$TESTCFI_$$_JOJO


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel