Let libipchw consumers drop vendor HALs they can never run on - #178
Merged
Conversation
libipchw carries a HAL for every supported vendor. They are only reachable through the detection table in chipid.c, so a consumer that already knows its SoC family links a pile of code that can never execute. --gc-sections does not help: the manufacturers[] table is a static array of function pointers, so every entry stays referenced. Add IPCHW_VENDORS, which selects the optional HALs compiled into the library: "all" (default, unchanged), "none", or a ;-separated subset. The HiSilicon HAL is always built because hw_detect_system() dispatches to it directly rather than through the table. On an ARM Release build this takes ipcinfo from 96208 to 87456 bytes (-8752, -9.1%) and libipchw.a from 150060 to 103064. Building with the default "all" is byte-identical to before. The ipctool executable is a diagnostic tool that has to run on anything, so it keeps every vendor regardless of the setting — it is 263456 bytes with "all", "none" and a subset alike. chipid.c gets a sentinel entry and a detect_fn check so manufacturers[] stays well-formed when every optional vendor is compiled out. ipcinfo's print_serial() guards its sstar_get_die_id() call, since that is a direct dependency on a HAL that may no longer be present. Verified on a Hi3516EV300 + IMX335: ipcinfo -c/-f/-s/-t report identical values built with "all" and with "none". Co-Authored-By: Claude Opus 4.8 <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
libipchwcarries a HAL for every supported vendor. They are only reachable through the detection table inchipid.c, so a consumer that already knows its SoC family links a pile of code that can never execute.--gc-sectionsdoes not help here —manufacturers[]is a static array of function pointers, so every entry stays referenced no matter what the linker does. The only way to drop them is to not compile them.Change
New cache variable
IPCHW_VENDORSselects which optional HALs go into the library:all— default, behaviour and output unchangednone— HiSilicon only;-separated subset, e.g.-DIPCHW_VENDORS="sstar;xm"The HiSilicon HAL is always built, because
hw_detect_system()dispatches to it directly rather than through the table.The
ipctoolexecutable is a diagnostic tool that has to run on anything, so it always compiles every vendor regardless of the setting.Measurements
ARM
Releasebuild:IPCHW_VENDORSipcinfolibipchw.aipctoolall(default)sstar;xmnonenonetakes 8,752 bytes (9.1%) offipcinfo.ipctoolis unchanged across all three, as intended.Building with the default
allproduces a byte-identical result to before this change.Notes on the implementation
chipid.cgets a sentinel entry plus adetect_fncheck in the loop, somanufacturers[]stays a well-formed non-empty array when every optional vendor is compiled out.ipcinfo'sprint_serial()guards itssstar_get_die_id()call. That is a direct dependency from a library consumer on a HAL that may no longer be present — worth knowing it exists.chipid.c) plus their own implementation file, which is why this stays small.Testing
Cross-built for ARM in all three configurations above;
ipcinfoandipctoolboth link cleanly in each.Verified on a Hi3516EV300 + IMX335 that detection is unaffected —
ipcinfo -c/-f/-s/-treport identical values built withalland withnone:🤖 Generated with Claude Code