#LLD
After updating #FreeBSD "src" today, an interesting comment for "#lld" caught my attention:
#llvm/lld: #damage_control_threading, https://cgit.freebsd.org/src/commit/?id=04bab189b8a54974fcd9530140e4eed6ad137f48
took me to
Avoidable overhead from threading by default, https://discourse.llvm.org/t/avoidable-overhead-from-threading-by-default/69160
via
llvm/lld: damage control threading, https://reviews.freebsd.org/D39389
#clang #lld #programming question: What is a good way to make blobs of data (say, C strings), contributed by a bunch of different compilation units and static libraries, be available for introspection at runtime?
I don’t want to use registration at load time. These blobs are constant and statically known. I want to introspect at run time “OK, what are all the blobs that my constituent parts contributed at link time?”
The #LinuxKernel has 2 #ELF loaders: one for executables and one for the interpreter (PT_INTERP). The latter is rather simple and expected only the last PT_LOAD to need zero padding. #LLD linking #musl's libc.so started doing this with multiple PT_LOADs...
Hopefully this will fix the bug
@dalias noticed:
https://lore.kernel.org/linux-hardening/20221111061315.gonna.703-kees@kernel.org/
I hope to merge these loaders in the future, but first we need better unit tests.
Eben die ersten #Flixtrain Wagen in der Behandlungsanalge wie auch immer die heißt bei #LLD stehen gesehen.
#DS100
@wwwcdorg Tu crois @sacem@twitter.com, ils vont penser à parler des #LicencesDeLibreDiffusion ?
#LLD #Copyleft #GNU
