Forum > Unix
Dynamic linkage on Linux x86_64 (calling back into main program)
MarkMLl:
About five years ago I put together a useful little Lazarus/LCL-based app which could collect data from a cheap oscilloscope, display it, apply an FFT and so on. I left it in this state:
--- Quote from: MarkMLl on January 29, 2021, 11:04:26 am ---Anybody who wants a copy is welcome, but I'm not sticking it onto Github yet. The issue is that the project can use dynamic linkage between the frontend (generic) and backend (device-specific) parts, and while the frontend could call the backend I was having problems with calls from the backend to frontend. The worrying thing is that it worked properly with 32-bit code (on a 64-bit Linux system with multiarch, FPC 3.0.4) but not with 64-bit code, and when I last looked at this I got bemired a long way into the runtimes and standard libraries.
--- End quote ---
I've just put a solid few days work into it, with a view to writing more instrument-specific backends, which has uncovered something "interesting".
The overall programming and in particular linkage style is something I used for a MIDI-filter program 10+ years ago, which worked sufficiently reliably that it was- as an example- able to pick up a recompiled backend on-the-fly. However at the time everything was 32-bit...
The main part of the app ("frontend") is able to call into the dynamically-linked .so library ("backend") reliably on both x86 (i386) and x86_64 (amd).
On x86, the backend can call into the frontend to recover its API magic number, display a dialog(ue) box and so on.
On x86_64, the backend cannot call into the frontend, even to recover an integer magic number.
I've now got that to a state where I can demonstrate a problem in dynlibs reliably, by asking the frontend to recover its own magic number via a dynamically-linked entry point: it works on x86, but not x86_64.
I think I remember Sven writing something about a fundamental change to the x86_64 calling conventions (relative to x86) a couple of months ago. Can anybody remind me of the detail before I concede defeat and attach a test project?
Currently using FPC 3.2.2, but was probably on 3.0 when I first became aware of the problem.
MarkMLl
cdbc:
Hi
On linux, I can call back and forth between lib & app with no obstacles.
I use NO declarations, i.e.: *no* 'cdecl' or 'stdcall' etc...
I use 'cmem' in both app & lib
All of this works for me on PCLinuxOS 64bit AMD.
I've also got some using fpc's sharemem, which I forked to linux and made dynamic... It too works.
I can even use strings arrays and com interfaces across library boundries...
Regards Benny
MarkMLl:
Absolutely definitely not working here. The specific case is exposing an entry point in the main program to allow a magic number to be recovered, which fails even if the main program tries to link to itself dynamically.
I agree about having cmem and broadly agree about the lack of other modifiers. I'm sufficiently confident in the underlying technology to e.g. copy menu structure from a (non-displayed) backend form to the frontend.
MarkMLl
cdbc:
Hi
Mark take a look at the attachment, it's just quick'n'dirty, but works here...
When you compile the library, just copy it to the host-directory...
Regards Benny
MarkMLl:
Will do, but apart from that I'm working on knocking redundant stuff out of my own program to make a decent POC.
And bringing up a machine with Debian-11 32- and 64-bit, to eliminate various other known problems: I spent a chunk of Saturday trying to get FPC 32-bit on Debian-12 and ultimately resolved that there were quite simply too many things in the way.
MarkMLl
Navigation
[0] Message Index
[#] Next page