[libcxx-commits] [libcxx] [libcxx] Support ABI symbol sizes on macOS (PR #75623)

[Will Hawkins via libcxx-commits]

================
@@ -193,6 +193,26 @@ split_list(LIBCXX_LINK_FLAGS)
 
 # Build the shared library.
 if (LIBCXX_ENABLE_SHARED)
+
+  if (APPLE)
+    # If we are on an Apple platform, let's ask the linker to generate a map
+    # that we can use to determine the size of the abi symbols (see generate-cxx-abilist target).
+    if (CMAKE_CXX_COMPILER_TARGET)
+      set(triple "${CMAKE_CXX_COMPILER_TARGET}")
+    else()
+      set(triple "${LLVM_DEFAULT_TARGET_TRIPLE}")
+    endif()
+    cxx_abi_identifier(abi_identifier
+      "${triple}"
+      "${LIBCXX_CXX_ABI}"
+      "${LIBCXX_ABI_VERSION}"
+      "${LIBCXX_ABI_UNSTABLE}"
+      "${LIBCXX_ENABLE_EXCEPTIONS}"
+      "${LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS}"
+    )
+    add_link_flags("-Wl,-map,${CMAKE_CURRENT_SOURCE_DIR}/../lib/abi/${abi_identifier}.linker.map")
----------------
hawkinsw wrote:



> Do we need the name of this map file to be unique across ABI-affecting properties? Can't we just always call it e.g. `linker.map`?

It *seems* like the answer is yes ... I think that the information in the map file will be just like the information in the other files named using the unique-ABI-affecting-properties quintuple (e.g., `libcxx/lib/abi/x86_64-unknown-freebsd.libcxxabi.v1.stable.exceptions.nonew.abilist`). 

That said, I may be missing the entire spirit of what you are asking ... upon consideration, I think I now recognize what you are asking:

_Will, why not generically name the map file `linker.map` during the build process and let `generate_abi_list.py` handle munging that raw data and emitting a file that is named uniquely according to the ABI-affecting properties?_

If that was the intent of your question/suggestion, then I completely agree and will make that change! The only potential downside: There is no way to ensure that the generated file with the generic name comes from the current target platform. The map file could persist long after it was generated and a person building libc++ could accidentally take their build directory to another platform and get odd results. I know that seems like something a competent builder would never do, but it does seem like something that *I* could do.

> 
> Also, I think we should avoid generating files in `CMAKE_CURRENT_SOURCE_DIR` since that will pollute the source directory. Instead we should probably generate into `CMAKE_CURRENT_BINARY_DIR` or something like that.

I will absolutely update the location of the generated linker map file. 


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