Change Details

It appears that compilers or linkers will reorder MODULE_METADATA linker set entries compared with program (source code) order. kldxref has previously relied on the assumption that MDT_MODULE was ordered first by having it ordered first in source code. (Or at least, devmatch(8) relied on MDT_MODULE sorting before MDT_PNP_INFO for correct association of klds and PNP tables.) So: just take two passes over a given .ko's module metadata, scanning for the MDT_MODULE on the first pass and the other metadata on subsequent passes. It's not super expensive and not exactly a performance-critical piece of code. This ensures MDT_MODULE is always ordered before MDT_PNP_INFO, regardless of compiler/linker movement. As a fringe benefit, it removes the requirement that care be taken to always order MODULE_PNP_INFO after DRIVER_MODULE in source code.

MDT_MODULE info is required to be ordered before any other MDT metadata for a given kld because it serves as an implicit record boundary between distinct klds for linker.hints consumers. kldxref(8) has previously relied on the assumption that MDT_MODULE was ordered relative to other module metadata in kld objects by source code ordering. However, C does not require implementations to emit file scope objects in any particular order, and it seems that GCC 6.4.0 and/or binutils 2.32 ld may reorder emitted objects with respect to source code ordering. So: just take two passes over a given .ko's module metadata, scanning for the MDT_MODULE on the first pass and the other metadata on subsequent passes. It's not super expensive and not exactly a performance-critical piece of code. This ensures MDT_MODULE is always ordered before MDT_PNP_INFO and other MDTs, regardless of compiler/linker movement. As a fringe benefit, it removes the requirement that care be taken to always order MODULE_PNP_INFO after DRIVER_MODULE in source code.

It appears that compilers or linkers will reorder MODULE_METADATA linker setMDT_MODULE info is required to be ordered before any other MDT metadata for entries compared with program (source code) order. kldxref has previouslya given kld because it serves as an implicit record boundary between relied on the assumption that MDT_MODULE was ordered first by having itdistinct klds for linker.hints consumers. kldxref(8) has previously relied ordered first in source code. (Or at least, devmatch(8) relied onon the assumption that MDT_MODULE was ordered relative to other module MDT_MODULE sorting before MDT_PNP_INFO for correct associmetadata in kld objects by source code ordering. However, C does not require implementation of klds ands to emit file scope objects in PNP tables.)any particular order, and it seems that GCC 6.4.0 and/or binutils 2.32 ld may reorder emitted objects with respect to source code ordering. So: just take two passes over a given .ko's module metadata, scanning for the MDT_MODULE on the first pass and the other metadata on subsequent passes. It's not super expensive and not exactly a performance-critical piece of code. This ensures MDT_MODULE is always ordered before MDT_PNP_INFO and other MDTs, regardless of compiler/linker movement. As a fringe benefit, fringe benefit, it removes the requirement that care be taken to always order order MODULE_PNP_INFO after DRIVER_MODULE in source code.