Re: [fpc-pascal] Separate debug info for release builds
On Fri, 1 Nov 2024 at 21:22, Nikolay Nikolov via fpc-pascal wrote: > Because Free Pascal doesn't support smartlinking+debug info on most > platforms. The only exception is macOS, where it is actually supported. Do you know why it's not supported? What are the barriers to supporting it? It's quite common to ship an optimised build with separate debug info so either the user can add them later to get a useful backtrace, or the developer can convert addresses to lines in gdb (info line *0x1234). Debian's debug packages work like this. > Adding --gc-sections to the linker on other platforms will probably > result in broken debug info and is not guaranteed to work. Of course, > you are encouraged to try it and test it, and see if it works, but it > probably doesn't. It works fine in a simple example, I'll test for larger builds. I'd be hesitant to ship something that isn't supported, though. That means I'll have to roll separate debug installers, which is a pain. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Separate debug info for release builds
On Fri, 1 Nov 2024 at 16:12, Henry Vermaak wrote: > On Fri, 1 Nov 2024 at 15:49, Martin Frb via fpc-pascal > wrote: > > Another factor could be that debug info affects smartlinking. Or leaves > > symbols for the linker in sections that are shared with non-debug info. > > This seems to be the problem. I think adding -g turns off > smartlinking, which then blows up the binary size, I've just tested > with and without (-CX -XX). Looks like I can "fix" this by passing --gc-sections to ld. Are there any fpc devs that can comment on why smart linking gets switched off when -g is passed? Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Separate debug info for release builds
On Fri, 1 Nov 2024 at 15:49, Martin Frb via fpc-pascal wrote: > Another factor could be that debug info affects smartlinking. Or leaves > symbols for the linker in sections that are shared with non-debug info. This seems to be the problem. I think adding -g turns off smartlinking, which then blows up the binary size, I've just tested with and without (-CX -XX). Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Separate debug info for release builds
On Fri, 1 Nov 2024 at 15:16, Martin Frb via fpc-pascal wrote: > On 01/11/2024 15:59, Henry Vermaak via fpc-pascal wrote: > I may not have all the factors, but O- O1 and O2 are not debug info, but > optimization. > So they generate different code, and that leads to different exe sizes. I understand that. I was comparing a build with (-O2) to a build with (-O2 -g -Xg). The -Xg isn't particularly relevant here, building with (-O2 -g) then stripping leaves you with a binary that's much larger than without -g. This works fine with gcc and the binaries are the same size after stripping. > I am not sure it explains the full size diff you get. Depending on the code, > you may have a difference due to smart linking. > > To check if any other symbols (e.g. those needed for the linker) differ > between the various builds, you can try to use strip, and that shows you how > much actually remains for the app-code/data. All binaries are fully stripped. > Then of course there are a few problems that make the whole thing more > complex. > > gcc can (afaik) generate working debug info for optimized code. > > fpc does not. If data is in registers then fpc does not represent that (at > least not always correctly) in the debug info. So data will be show incorrect > in the debugger. > fpc does not generate line info for inlined code. And I don't know how > well/exact line info is for different level of optimization in different fpc > versions. > And some versions of fpc (or maybe some linkers?) caused broken debug info > when smart linking was enabled. > > So basically, if you want to debug, then you can't really optimize. > Or at least you must check exactly what is supported by the version of fpc > you use. Sure, I understand that optimising messes up debugging, I just want a stack trace that points me in the general direction of what's going wrong (and that works OK in simple tests). Except if fpc ignores -O2 somehow when I pair it with -g? Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Separate debug info for release builds
When I add -Xg, the compiler writes the debug info into a separate .dbg file and adds a .gnu_debuglink section so the debugger can find the info. So far so good (and simpler than having the use objcopy). The size of the binary is much larger than building without debug info, though. E.g. with -O2 it goes from 35K to 188K. When I do exactly the same with gcc (via objcopy and strip), there's almost no difference between the stripped binary and a binary built without debugging info (even diffing objdump output). Can anyone explain why this is? Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Function to create a record ?
On Fri, 2 Jun 2023 at 01:36, Steve Litt via fpc-pascal wrote: > fillchar(junkvar, junkvar_size, 'b'); > person := modperson(person, 'Martin'); > person := modperson(person2, 'Maria'); Maybe a typo? (E.g. person2 := modperson(person2, 'Maria')) Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] I am offering a $100 reward for linking static libraries
On Thu, 25 Aug 2022 at 04:08, Anthony Walter via fpc-pascal
wrote:
> I've written a utility to extract mingw64 static library exports into a
> searchable database. This allows me to search for possible missing functions
> (see the screenshot below)
>
> https://cache.getlazarus.org/images/desktop/raylib-static.png
Note for anyone with msys2, you can make a file containing all defined
external symbols like this:
# find /mingw64/lib -name "*.a" -exec nm -pogC --defined-only '{}' \;
2>/dev/null >> symbs.txt
Then search it with grep:
hcv@hcv-l14 MINGW64 ~
# grep -w atexit symbs.txt
C:/msys64/mingw64/lib/libmsvcr120.a:libmsvcr120_defs01591.o:
T atexit
C:/msys64/mingw64/lib/libmsvcr120_app.a:libmsvcr120_app_defs01268.o:
T atexit
C:/msys64/mingw64/lib/libmsvcr120d.a:libmsvcr120d_defs01654.o:
T atexit
hcv@hcv-l14 MINGW64 ~
# grep -w sincos symbs.txt
C:/msys64/mingw64/lib/libmingwex.a:lib64_libmingwex_a-cossin.o:
T sincos
Henry
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] I am offering a $100 reward for linking static libraries
On Mon, 22 Aug 2022 at 22:42, Pierre Muller via fpc-pascal wrote: > Le 22/08/2022 à 18:18, Henry Vermaak via fpc-pascal a écrit : > > On Sun, 21 Aug 2022 at 18:34, Anthony Walter via fpc-pascal > > wrote: > >> I am also able to use mingw32 gcc to compile this same C source into a > >> static library for Windows using these two commands while inside the > >> folder containing the Chipmunk2D sources: > >> > >> x86_64-w64-mingw32-gcc-win32 -static -static-libgcc -std=gnu99 -ffast-math > >> src/*.c -Iinclude -c > > > > -static and -static-libgcc are linking options, so they won't do > > anything here. You'll have to link libgcc in manually in your pascal > > source. > >You can always pass option to the external linker using '-k' option: > Use -k-static (without space) > or -k-lc > or -k-L -k/DIR/ Without -static-libgcc you'll still have to figure out which archives make up libgcc. ld won't do that for you. Either way I think that unless fpc can be built with the same toolchain as the C libs you're linking with there may be too many things that can go wrong. E.g. I'm getting 0-bit reloc in dll errors with the external linker. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] I am offering a $100 reward for linking static libraries
On Sun, 21 Aug 2022 at 18:34, Anthony Walter via fpc-pascal
wrote:
> I am also able to use mingw32 gcc to compile this same C source into a static
> library for Windows using these two commands while inside the folder
> containing the Chipmunk2D sources:
>
> x86_64-w64-mingw32-gcc-win32 -static -static-libgcc -std=gnu99 -ffast-math
> src/*.c -Iinclude -c
-static and -static-libgcc are linking options, so they won't do
anything here. You'll have to link libgcc in manually in your pascal
source.
> {$ifdef windows}
> {$linklib mingw32}
> {$linklib mingwex}
> {$linklib kernel32}
> {$linklib msvcrt}
> {$linklib chipmunk-win}
> {$endif}
>
> I get many errors similar to these below:
>
> Verbose: Compiling resource
> C:\Development\Projects\physics\lib\x86_64-win64\Physics.obj
> Verbose: Linking C:\Development\Pascal\Projects\physics\Physics.exe
> Physics.lpr(30,1) Error: Undefined symbol: ___chkstk_ms
> Physics.lpr(30,1) Error: Undefined symbol: __mingw_raise_matherr
> Physics.lpr(30,1) Error: Undefined symbol: __imp_WideCharToMultiByte
> Physics.lpr(30,1) Error: Undefined symbol: __imp_IsDBCSLeadByteEx
> Physics.lpr(30,1) Error: Undefined symbol: __imp_MultiByteToWideChar
> Physics.lpr(30,1) Verbose: There were 5 errors compiling module, stopping
> Verbose: Compilation aborted
The order of the linklib entries make a difference. I can get the
undefined symbols down to nothing by using this order:
{$linklib libchipmunk.a}
{$linklib libmingwex.a}
{$linklib libmingw32.a}
{$linklib libgcc.a}
//{$linklib libmsvcrt.a}
{$linklib libmsvcr120.a}
{$linklib libkernel32.a}
But then I get an internal error (200603061). It may be down to the
toolchain/libraries I used (recent msys2 x64), which would be a lot
newer than fpc (I should really try to package it for msys2 when I
have some free time).
Henry
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Option type
On Tue, 1 Jun 2021, 23:39 Ryan Joseph via fpc-pascal, < fpc-pascal@lists.freepascal.org> wrote: > > > > On Jun 1, 2021, at 12:56 PM, denisgolovan > wrote: > > > > That would limit supported types to class instances. > > I'll like to avoid that. > > Ideally TOption type should allow any type (primitives, strings, > objects, class instances, etc). > > What are you trying to make that requires a variant record? I don't know > what "TOption" is. https://en.wikipedia.org/wiki/Option_type Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to find where my app consumes CPU?
On Wed, 19 May 2021 at 14:36, Travis Siegel via fpc-pascal wrote: > > No doubt your sleep code works just fine. > > I'm not saying the sleep command doesn't work. > > I'm saying the sleep command doesn't release unused cpu cycles for other > threads/programs to use. No, fpc uses nanosleep() inside sysutils.sleep() which is documented to suspend execution (i.e. no busy waiting) so the kernel will switch to another thread/process. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FTP support gone - switch to HTTP ?
On Tue, 18 May 2021 at 11:50, Sven Barth via fpc-pascal wrote: > I don't think we need to mention any specific clients (and why did your list > not include Filezilla? :P ) Because FileZilla bundles adware when you download from the homepage? Would actually be good to warn _against_ using it. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] OpenCV
On Thu, 13 Feb 2020 at 13:26, Adriaan van Os wrote: > > > I looked around on the web for OpenCV Pascal bindings. What I found, seems to > be based (mostly) on > the OpenCV C interfaces, which covers only part of OpenCV. > > Alternatives are: >8--- > 2. Hook into the Python wrapper/bindings generator > I think using the python/java generator is the only way to make anything that resembles a complete binding. As an intermediate step I hoped that the generated C bindings could be run through h2pas, but h2pas has never worked without manual tinkering for me. In the long run a class-based binding would be great to have. I've been meaning to look into this, but digging through thousands of lines of python is not my idea of fun. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
