[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:

I'm not especially up-to-speed on the MC/CodeGen way of doing things, so some of what I suggest may not work, but some general thoughts here:

1) I'd add a section header before the functions in text are emitted.
2) While iterating over each function, you'd switch to the function map section and emit the entry corresponding to that function at some point. Take a look at how .stack_sizes (-fstack-size-section) works for a simple example of this.
3) I would hope you can use labels in the assembly to calculate the size, i.e. something along the lines of:

```
# The header part of .llvm_func_map
.section .llvm_func_map ...
  .quad func_map_end - func_map_start
func_map_start:
  .byte 1 # version

# Emit functions here...

# "End" of the .llvm_func_map section
.section .llvm_func_map ...
func_map_end:
```
However, I don't have a sensible answer for COMDAT sections and, more importantly perhaps, --gc-sections (or indeed linker section deduplication). You could have individual entries in separate sections, which are then discarded when their parent sections are, but I'm not sure whether you could guarantee that the header and tail sections remain in the right order relative to the entries. DWARF sections dodge this by (suboptimally) keeping the dead entries and having a "tombstone" value for the address of entries that are considered irrelevant.

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