Forum > General
FPC 3.2.2 - Debug Information's are always present
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:
--- Quote from: paule32 on October 28, 2024, 10:29:19 am ---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.
--- End quote ---
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:
--- Quote from: paule32 on October 28, 2024, 10:38:45 am ---sorry for my blah blah ...
It's OK, but that /was/ quite a long and detailed thread :-)
--- End quote ---
--- Quote ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page