Skip to content

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant