This patch fixes: llvm/lib/DebugInfo/GSYM/FunctionInfo.cpp:321:7: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
This update introduces the ability to filter merged functions during lookups based on regex patterns derived from call site information in a previous call to `llvm-gsymutil`. The regex patterns, extracted from call sites, can then be passed to subsequent calls using the `--merged-functions-filter` option along with `--merged-functions` and `--address` (or `--addresses-from-stdin`). This allows for precise filtering of functions during lookups, giving accurate results for call stacks that contain merged functions.
Adds the ability to lookup and display all merged functions for an address in llvm-gsymutil. Now, when `--merged-functions` is used in combination with `--address/--addresses-from-stdin`, lookup results will contain information about merged functions, if available. To support printing merged function information when using the `--verbose` option, the `LookupResult` data structure also had to be extended with pointers to the raw function data and raw merged function data. This is because merged functions share the same address range, so it's not easy to look up the raw merged function data for a particular `LookupResult` that is based on a merged function.
This PR adds support in the gSYM format for call site information and adds support for loading call sites from a YAML file. The support for YAML input is mostly for testing purposes - so we have a way to test the functionality. Note that this data is not currently used in the gSYM tooling - the logic to use call sites will be added in a later PR. The reason why we need call site information in gSYM files is so that we can support better call stack function disambiguation in the case where multiple functions have been merged due to optimization (linker ICF). When resolving a merged function on the callstack, we can use the call site information of the calling function to narrow down the actual function that is being called, from the set of all merged functions. See [this RFC](https://discourse.llvm.org/t/rfc-extending-gsym-format-with-call-site-information-for-merged-function-disambiguation/80682) for more details on this change.
This patch introduces support for storing debug info for merged functions in the GSYM debug info. It allows GSYM to represent multiple functions that share the same address range, which occur when multiple functions are merged during linker ICF. The core of this functionality is the new `MergedFunctionsInfo` class, which is integrated into the existing `FunctionInfo` structure. During GSYM creation, functions with identical address ranges are now grouped together, with one function serving as the "master" and the others becoming "merged" functions. This organization is preserved in the GSYM format and can be read back and displayed when dumping GSYM information. Old readers will only see the master function, and ther "merged" functions will not be processed. Note: This patch just adds the functionality to the gSYM format - additional changes to the gsym format and algorithmic changes to logic existing tooling are needed to take advantage of this data. Exact output of `llvm-gsymutil --verify --verbose` for the included test: [gist](https://gist.github.com/alx32/b9c104d7f87c0b3e7b4171399fc2dca3)
system_endianness() just returns llvm::endianness::native, a
compile-time constant equivalent to std::native in C++20. This patch
deprecates system_endianness() while replacing all invocations of
system_endianness() with llvm::endianness::native.
While we are at it, this patch replaces
llvm::support::endianness::{big,little} with
llvm::endianness::{big,little} in those statements that happen to call
system_endianness(). It does not go out of its way to replace other
occurrences of llvm::support::endianness::{big,little}.
Some workflows can generate large GSYM files and sharding GSYM files into segments can help some performant workflows that can take advantage of smaller GSYM files. This patch add a new --segment-size option to llvm-gsymutil. This option can specify a rough size in bytes of how large each segment should be. Segmented GSYM files contain only the strings and files that are needed for the FunctionInfo objects that are added to each shard. The output file path gets the first address of the first contained function info appended as a suffix to the filename. If a base address of an image is set in the GsymCreator, then all segments will use this same base address which allows lookups for symbolication to happen correctly when the image has been slid in memory. Code has been addeed to refactor and re-use methods within the GsymCreator to allow for segments to be created easily and tested. Example of segmenting GSYM files: $ llvm-gsymutil --convert llvm-gsymutil.dSYM -o llvm-gsymutil.gsym --segment-size 10485760 $ ls -l llvm-gsymutil.gsym-* -rw-r--r-- 1 gclayton staff 10485839 Feb 9 10:45 llvm-gsymutil.gsym-0x1000030c0 -rw-r--r-- 1 gclayton staff 10485765 Feb 9 10:45 llvm-gsymutil.gsym-0x100668888 -rw-r--r-- 1 gclayton staff 10485881 Feb 9 10:45 llvm-gsymutil.gsym-0x100c948b8 -rw-r--r-- 1 gclayton staff 10485954 Feb 9 10:45 llvm-gsymutil.gsym-0x101659e70 -rw-r--r-- 1 gclayton staff 10485792 Feb 9 10:45 llvm-gsymutil.gsym-0x1022b1dc0 -rw-r--r-- 1 gclayton staff 10485889 Feb 9 10:45 llvm-gsymutil.gsym-0x102a18b10 -rw-r--r-- 1 gclayton staff 10485893 Feb 9 10:45 llvm-gsymutil.gsym-0x1030b05d0 -rw-r--r-- 1 gclayton staff 10485802 Feb 9 10:45 llvm-gsymutil.gsym-0x1037caaac -rw-r--r-- 1 gclayton staff 10485781 Feb 9 10:45 llvm-gsymutil.gsym-0x103e767a0 -rw-r--r-- 1 gclayton staff 10485832 Feb 9 10:45 llvm-gsymutil.gsym-0x10452d0d4 -rw-r--r-- 1 gclayton staff 10485782 Feb 9 10:45 llvm-gsymutil.gsym-0x104b93310 -rw-r--r-- 1 gclayton staff 6255785 Feb 9 10:45 llvm-gsymutil.gsym-0x10526bf34 Differential Revision: https://reviews.llvm.org/D145448
This reverts commit fe758254181a824d73ad960b651b42f671f8936b. This change was causing several buildbot failures: - https://lab.llvm.org/buildbot/#/builders/38/builds/10105 - https://lab.llvm.org/buildbot/#/builders/192/builds/562 - https://lab.llvm.org/buildbot/#/builders/109/builds/58893 - https://lab.llvm.org/buildbot/#/builders/16/builds/44360 - https://lab.llvm.org/buildbot/#/builders/247/builds/2095 - https://lab.llvm.org/buildbot/#/builders/196/builds/27236 - https://lab.llvm.org/buildbot/#/builders/54/builds/3714
Some workflows can generate large GSYM files and sharding GSYM files into segments can help some performant workflows that can take advantage of smaller GSYM files. This patch add a new --segment-size option to llvm-gsymutil. This option can specify a rough size in bytes of how large each segment should be. Segmented GSYM files contain only the strings and files that are needed for the FunctionInfo objects that are added to each shard. The output file path gets the first address of the first contained function info appended as a suffix to the filename. If a base address of an image is set in the GsymCreator, then all segments will use this same base address which allows lookups for symbolication to happen correctly when the image has been slid in memory. Code has been addeed to refactor and re-use methods within the GsymCreator to allow for segments to be created easily and tested. Example of segmenting GSYM files: $ llvm-gsymutil --convert llvm-gsymutil.dSYM -o llvm-gsymutil.gsym --segment-size 10485760 $ ls -l llvm-gsymutil.gsym-* -rw-r--r-- 1 gclayton staff 10485839 Feb 9 10:45 llvm-gsymutil.gsym-0x1000030c0 -rw-r--r-- 1 gclayton staff 10485765 Feb 9 10:45 llvm-gsymutil.gsym-0x100668888 -rw-r--r-- 1 gclayton staff 10485881 Feb 9 10:45 llvm-gsymutil.gsym-0x100c948b8 -rw-r--r-- 1 gclayton staff 10485954 Feb 9 10:45 llvm-gsymutil.gsym-0x101659e70 -rw-r--r-- 1 gclayton staff 10485792 Feb 9 10:45 llvm-gsymutil.gsym-0x1022b1dc0 -rw-r--r-- 1 gclayton staff 10485889 Feb 9 10:45 llvm-gsymutil.gsym-0x102a18b10 -rw-r--r-- 1 gclayton staff 10485893 Feb 9 10:45 llvm-gsymutil.gsym-0x1030b05d0 -rw-r--r-- 1 gclayton staff 10485802 Feb 9 10:45 llvm-gsymutil.gsym-0x1037caaac -rw-r--r-- 1 gclayton staff 10485781 Feb 9 10:45 llvm-gsymutil.gsym-0x103e767a0 -rw-r--r-- 1 gclayton staff 10485832 Feb 9 10:45 llvm-gsymutil.gsym-0x10452d0d4 -rw-r--r-- 1 gclayton staff 10485782 Feb 9 10:45 llvm-gsymutil.gsym-0x104b93310 -rw-r--r-- 1 gclayton staff 6255785 Feb 9 10:45 llvm-gsymutil.gsym-0x10526bf34 Differential Revision: https://reviews.llvm.org/D143793
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716