FPC 3.2.2 - Debug Information's are always present

[paule32]

Hi,
I used the command line tool FPC with option: -g-

I read, that this option will turn off the generating of debug information's - but when I look to the created assembly, the debug symbols and a bunch of code in SECTION .debug_frame can be found.
Is there no way to force it out ?

[TRon]

have you tried icw -Xs and if that isn't enough using strip binutil manually ?

[paule32]

yes, I tried:

Code: Bash  [Select][+][-]

1. ppcrossx64.exe -Xs -Fu..\sources\fpc-sys -Anasmwin64 -a -g- test.pas

but the debug_frame SECTION is still present.
I know strip.exe.
But I was thinking, that the DEBUG stage contains extra binary code in the image...

[MarkMLl]

Roughly translated: you'd expect to see debug info in the assembly output since whether it's in the binary or not is determined by the linker. In extremis, you can use the strip command (part of binutils) to remove debug info from the final binary, although as you'll see from a recent thread (and I'm sure you did a bit of research before posting) that doesn't remove RTTI.

MarkMLl

[TRon]

Indeed MarkMLI.

In the other thread paule32 was using objdump so was expecting that and not the assembler output created by the compiler. My bad.

[paule32]

the RTTI is a thing, that can be outsource to external file - because not all users/developers need RTTI all the time.
In the documentation, I could found the source code switch: {$M-}
This switch off RTTI.

But that is non-sense, because if I use "published" class properties, the RTTI will automatically force a [$M+}
which means, I have RTTI in the .exe cutable binary file.

[MarkMLl]

the RTTI is a thing, that can be outsource to external file - because not all users/developers need RTTI all the time.
In the documentation, I could found the source code switch: {$M-}
This switch off RTTI.

But that is non-sense, because if I use "published" class properties, the RTTI will automatically force a [$M+}
which means, I have RTTI in the .exe cutable binary file.

There's really no need to waste our time by rehashing what was discussed ad-nauseam in the other thread.

You asked about debugging symbols: are you able to remove /those/ from your final binary or do you still have a problem that you need help with?

MarkMLl

[paule32]

sorry for my blah blah ...

I was asking, when debug informations are defined in the assembly, then I was thinking that debug binary data exists between the normal .exe cutable.

Because, in other DSL I saw, that extra code was compiled in, and when strip.exe was used, the dwarf informations fly away from .exe but there was some gap's in the binary - so I was thinking, that FPC does the same.
Or I wrong ?

[MarkMLl]

sorry for my blah blah ...

It's OK, but that /was/ quite a long and detailed thread :-)

I was asking, when debug informations are defined in the assembly, then I was thinking that debug binary data exists between the normal .exe cutable.

Because, in other DSL I saw, that extra code was compiled in, and when strip.exe was used, the dwarf informations fly away from .exe but there was some gap's in the binary - so I was thinking, that FPC does the same.

Pascal is not a DSL, it's a full compiler (although I /am/ inclined to compare FPC+Lazarus- usually favourably- with 1990s-style "4GLs").

Debug /code/ that you choose to insert is distinct from debug /symbols/. The various linker-control options (-g etc.) as well as the strip binary will- at least on unix-derived OSes- remove the parts of the executable that contain symbolic debug info, i.e. the addresses corresponding to each function entry and to each line number which I think you've identified in the assembly output.

Leaving aside RTTI, control of assertions and control of run-time checks etc. is by compiler option, and neither a -g- nor a subsequent strip will remove those. I'm not sure (without checking) what happens to assertion error messages if the compiler is told to not to include assertion code: I'd hope that they were completely ignored. But there was another thread on assertions a couple of days ago...

Now, you'll obviously note that I've specifically mentioned unix-derived OSes above. However I suspect (although you've not told us explicitly which TBH you should have done) that you're using Windows, and there's always a chance that strip is not as thorough on a .EXE as it is on an ELF file: I'm pretty sure that you're up to using a file viewer to check, and if you could demonstrate that debug info ("of use to the enemy", not to mention bloat) wasn't being removed when it should be I think that would be of general interest.

MarkMLl

[marcov]

It might also depend on the -Anasm  stage, that that doesn't grok smartlinking.

Try to use the normal assembler backend and see if that smartlinks.

[paule32]

Hello @marcov

I have create two quick screen shots, so it could help someone else to decide, if the developer would be use LazIDE or a Text Editor like Notepad++ under Windows.
Each of them (IDE and Text Editor) have it pro and cons.

But I like notepad++ - its clean and supports syntax highlighting, too.
For the working with files, I use the FAR Manager - a Norton like File Commander (Editor, Viewer, ...)

[rvk]

But that is non-sense, because if I use "published" class properties, the RTTI will automatically force a [$M+}
which means, I have RTTI in the .exe cutable binary file.

You could look at this topic: Re: How To Disable RTTI ?
https://forum.lazarus.freepascal.org/index.php/topic,15880.msg85771.html#msg85771