[llvm] [SHT_LLVM_FUNC_MAP][ObjectYaml]Introduce function address map section and emit dynamic instruction count(ObjectYaml part) (PR #124332)

[James Henderson via llvm-commits]

================
@@ -535,6 +535,27 @@ Example of BBAddrMap with PGO data:
    .uleb128  1000                         # BB_3 basic block frequency (only when enabled)
    .uleb128  0                            # BB_3 successors count (only enabled with branch probabilities)
 
+``SHT_LLVM_FUNC_MAP`` Section (function address map)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+This section stores the mapping from the binary address of function to its
+related metadata features. It is used to emit function-level analysis data and
+can be enabled through ``--func-map`` option. The fields are encoded in the
+following format:
+
+#. A version number byte used for backward compatibility.
----------------
jh7370 wrote:

With fixed-sized entries, you can then use a binary search algorithm to search the section for a specific address, assuming that the entries are in address order. I _think_ this will be guaranteed by the SHF_LINK_ORDER flag. You might want to set the seciton's `sh_entsize` appropriately too.

Some related thoughts:
1) If the function addresses are ordered, you can use a binary search algorithm to find the specific one you care about, without needing to read any extra data at all (just the ones that get picked in the search) but only if the entry sizes are fixed.
2) I imagine that a future version of the structure might change the size of entries. In this case, you could end up with two objects with function maps of different versions and then different sh_entsize values. I've forgotten how linkers handle this. My hope is that in such a situation they set the sh_entsize to 0 for the combined section, but you'd need to check. A value of 0 would then mean that "fast traversal via binary search without reading the full structure first" isn't possible (in that case, you'd need to read each entry sequentially, although you could skip the data that isn't actually important after checking the version number to determine the size).

https://github.com/llvm/llvm-project/pull/124332