On Pá 12-03-21 14:28:50, Gabriel F. T. Gomes wrote: [...]
Before I start exploring this possibility further, do you think that it's OK to leverage the dynamic linker for preloading libpulp?
Do you mean the use of "-lpulp", so you get rid of LD_PRELOAD?
Yes. Sorry for leaving out the details.
I don't see any problems with it, though I should add that ld's -as-needed flag (which is used by default in OBS builds) would break that, because your library (or any to-be-made-livepatchable library, for that matter) doesn't actually depend on libpulp.so; thus, you might need to use: -Wl,-no-as-needed -lpulp.
Understood. Thanks for the hint!
I'm not sure what's the main purpose of using LD_PRELOAD. The only advantages (as compared to hard-coding libpulp.so.N into NEEDED entries in the Elf file) I can think of are: 1. one less package on your system if you don't want live-patching; 2. Being able to selectively enable live-patches on a process-by-process basis.
I don't know the history of the LD_PRELOAD thing either. I suspect, however, that no one evaluated the options so far. :)
I can imagine users may want to build "live patchable" applications, and perhaps also patchable shared libraries. In that can thay may want reference libpulp from the shared library.
I think I see what you mean... You would like to be able to create a package with a library that is live-patchable out-of-the-box, right? For instance, if someone installs your package for libworkload, then all projects linked against it will produce live-patchable applications which, when executed, start live-patchable processes (even if LD_PRELOAD is not used). Is that what you mean?
Exactly. Complicated start scripts of some applications (e.g., Firefox has a shell script to start the main process, Android Studio has similar shell magic) brought me to the idea. It might be complicated to stick an LD_PRELOAD into the start-up mechanism, or it might be outright impossible to do so when the native binary is called from, e.g., a proprietary Java code. At that point, I imagined a user who would like to live-patch a certain shared library, which is in use by a complicated application, without changing the application itself. Not that someone has asked. I'm merely presuming the demand.
If so, I don't know how end-users want libpulp to behave... Not yet.
Your use case is a good hint for me, though... Initially, I thought everybody would prefer the LD_PRELOAD approach, so the package at OBS (home:ULP) doesn't even distributes libpulp.so in the development package (only libpulp.so.0 on the library package), as explained in the spec file:
%install (...) # Remove .la and .so files. libpulp.so is not supposed to be linked # against any programs or libraries, but LD_PRELOAD'ed, so do not # distribute it, not even in the devel package. find %{buildroot}/%{_prefix} -name libpulp.la -delete find %{buildroot}/%{_prefix} -name libpulp.so -delete
(lines 92-96 in https://build.opensuse.org/package/view_file/home:ULP/libpulp/libpulp.spec?e...)
Perhaps that should go away, so that users can do like you and use -lpulp.
I can imagine that someone would even want to statically link libpulp into their app. But we are at the beginning and I'm merely exploring the possibilities. Thanks for your insights, Gabriel! Libor -- Libor Pechacek SUSE Labs Remember to have fun...