Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

drivers: construct driver list at runtime #233

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

fenugrec
Copy link
Contributor

@fenugrec fenugrec commented Nov 22, 2023

Relying on linker politeness could fail when compiled with -flto : https://sigrok.org/bugzilla/show_bug.cgi?id=1433

Instead of using a special section that holds a pointer to each of the driver descriptors, use__attribute__((constructor)) to run a certain function at runtime just before main() entry.
That is also before glib init and possibly (unclear) before heap is usable, so it may not be possible to directly build a GArray or GSList. A simple linked-list provides the intermediate step, and sr_drivers_init() still builds the final driver list via a GArray.

This compiler attribute is well-supported by gcc and clang.

It would possible to simplify this if struct sr_dev_driver had a 'next' member.

The SR_REGISTER_DEV_DRIVER_LIST() implementation is also not very elegant, but is a drop-in replacement.

Relying on linker politeness could fail when compiled with -flto :
https://sigrok.org/bugzilla/show_bug.cgi?id=1433

Instead of using a special section that holds a pointer to each of the
driver descriptors, use "__attribute__((constructor))" to run a certain
function at runtime just before main() entry.
That is also before glib init and possibly (unclear) before heap is
usable, so it may not be possible to directly build a GArray or GSList.
A simple linked-list provides the intermediarey step, and
sr_drivers_init() still builds the final driver list via a GArray.

This compiler attribute is well-supported by gcc and clang.

The SR_REGISTER_DEV_DRIVER_LIST() implementation is also not very
elegant, but is a drop-in replacement.
if no drivers were compiled, the for() loop can safely remain.
Each struct sr_dev_driver is writable, but the array of pointers to
those structs can be const.
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant