On Thu, 2023-07-06 at 18:38 -0400, Frank Henigman wrote:
>
> It's the LTO bug:
> https://sigrok.org/bugzilla/show_bug.cgi?id=1433
Still need to learn what's WRONG about that sigrok approach of
collecting a list of driver pointers. YES I can see how it's
unexpected to some, or how they think it's unnecessarily
complicated (ignoring the fact that other suggested approaches
are even more complicated and were discarded for $PURPOSE). And
YES the linker section collection broke in more recent setups
which aggressively change the incoming instructions instead of
just trivially executing them and be done. But let me repeat my
question:
What's _wrong_ with the current implementation? Beyond just
"didn't work in _my_ setup" or "it's unexpected to me to do it
that way" -- which are totally different questions.
The other question is what to do about that sigrok implementation
because LTO certainly isn't going away anytime soon. That's why I
started that (unfortunately named) autotools experiment repo.
It's actually rather specific to the libsigrok driver collection
issue, just happens to use autotools as the libsigrok build does,
to see the approach's taking effect (or not) and building (or
not) in the very context where libsigrok will use it. Have yet to
receive feedback from users especially on those platforms which
are not Linux. Because sigrok being portable, and caring about
more than a single target ...
The other approaches suggested most probably won't fly (unless
somebody steps up to implement and maintain them, beyond just
"suggesting it should be done", meaning that SomebodyElse(TM)
gets to do it). Code duplication in build instructions to
re-invent what's done in the source is not maintainable, and was
dropped in the past. Plugins require a stable public API of
what's currently mostly internal, or code duplication across many
plugins. But more than that loading shared libraries involves ...
shared libraries which not all supported platforms are using,
platform dependent filesystem traversal, platform dependent
linker magic for symbol visibility and other headaches, while the
benefit is rather questionable.
Am suspecting that the NULL termination of the drivers list is
the most pressing issue for LTO setups. When the list starts with
the terminator, and other entries follow ... the list would be
empty. This seems to be what users experience. But: Runtime needs
to learn where the list starts, and where it ends. Which gets us
back to "linker magic". Unless somebody comes up with a portable
approach to getting the start and end symbol, or to (get the
start and) pad the list with terminators, which doesn't involve
linker scripts ... Haven't seen any working suggestion so far.
Currently it's assumed that the C language "constructor" approach
is most portable and most robust at the same time. Runtime cost
is acceptable (until proven otherwise). That's what I outlined in
the autotools experiment of mine, which needs more testing (see
above). Without more users getting involved, it'll bitrot and
nothing will happen in mainline. As you could observe so far.
Fortunately list construction is concentrated in very few
locations in the source tree. Driver source code doesn't care at
all. It just calls into a "register the driver please" something.
It's only the implementation of "register another item with the
list", the actual embedding of the list in the resulting binary,
and the runtime traversal of that list whatever it may look like.
Sort order isn't an issue either. Only termination is, unless we
can tell the start and end by other means.
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
