Revision tags: llvmorg-21-init, llvmorg-19.1.7 |
|
#
6f28b4b5 |
| 06-Jan-2025 |
alx32 <103613512+alx32@users.noreply.github.com> |
[GSYM] Add support for querying merged functions in llvm-gsymutil (#120991)
Adds the ability to lookup and display all merged functions for an
address in llvm-gsymutil.
Now, when `--merged-funct
[GSYM] Add support for querying merged functions in llvm-gsymutil (#120991)
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.
show more ...
|
Revision tags: llvmorg-19.1.6 |
|
#
d0155789 |
| 13-Dec-2024 |
alx32 <103613512+alx32@users.noreply.github.com> |
[llvm-gsymutil] Fix dumping of call sites for merged functions (#119759)
Currently, when dumping the contents of a GSYM there are three issues: - Callsite information is not displayed for merged fun
[llvm-gsymutil] Fix dumping of call sites for merged functions (#119759)
Currently, when dumping the contents of a GSYM there are three issues: - Callsite information is not displayed for merged functions - this is because of a bug in `CallSiteInfoLoader::buildFunctionMap` where when enumerating through `Func.MergedFunctions` - we enumerate by value instead of by reference. - There is no variable indent for printing callsite info - meaning that when printing callsites for merged functions, the indent will be different than the other info of the merged function. To address this we add configurable indent for printing callsite info - Callsite info is printed right after merged function info. Meaning that if the merged function also has call site information, the parent's callsite info will appear right after the merged function's callsite info - leading to confusion. To address this we print the callsite info first, then the merged functions info.
This change addresses all the above 3 issues. Example of old vs new:
<img width="1074" alt="image" src="https://github.com/user-attachments/assets/d039ad69-fa79-4abb-9816-eda9cc2eda53" />
show more ...
|
Revision tags: llvmorg-19.1.5 |
|
#
5147e594 |
| 27-Nov-2024 |
alx32 <103613512+alx32@users.noreply.github.com> |
[GSYM] Callsites: Add data format support and loading from YAML (#109781)
This PR adds support in the gSYM format for call site information and adds support for loading call sites from a YAML file.
[GSYM] Callsites: Add data format support and loading from YAML (#109781)
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.
show more ...
|
Revision tags: llvmorg-19.1.4 |
|
#
0060c54e |
| 17-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[DebugInfo] Remove unused includes (NFC) (#116551)
Identified with misc-include-cleaner.
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3 |
|
#
cb5dc1fa |
| 07-Aug-2024 |
alx32 <103613512+alx32@users.noreply.github.com> |
[gSYM] Add support merged functions in gSYM format (#101604)
This patch introduces support for storing debug info for merged
functions in the GSYM debug info. It allows GSYM to represent multiple
[gSYM] Add support merged functions in gSYM format (#101604)
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)
show more ...
|
Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6 |
|
#
18eefc18 |
| 17-Nov-2023 |
Greg Clayton <gclayton@fb.com> |
Modify llvm-gsymutil lookups to handle overlapping ranges correctly. (#72350)
llvm-gsymutil allows address ranges to overlap. There was a bug where if
we had debug info for a function with a range
Modify llvm-gsymutil lookups to handle overlapping ranges correctly. (#72350)
llvm-gsymutil allows address ranges to overlap. There was a bug where if
we had debug info for a function with a range like [0x100-0x200) and a
symbol at the same start address yet with a larger range like
[0x100-0x300), we would randomly get either only information from the
first or second entry. This could cause lookups to fail due to the way
the binary search worked.
This patch makes sure that when lookups happen we find the first address
table entry that can match an address, and also ensures that we always
select the first FunctionInfo that could match. FunctionInfo entries are
sorted such that the most debug info rich entries come first. And if we
have two ranges that have the same start address, the smaller range
comes first and the larger one comes next. This patch also adds the
ability to iterate over all function infos with the same start address
to always find a range that contains the address.
Added a unit test to test this functionality that failed prior to this
fix and now succeeds.
Also fix an issue when dumping an entire GSYM file that has duplicate address entries where it used to always print out the binary search match for the FunctionInfo, not the actual data for the address index.
show more ...
|
Revision tags: llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3 |
|
#
4a0ccfa8 |
| 13-Oct-2023 |
Kazu Hirata <kazu@google.com> |
Use llvm::endianness::{big,little,native} (NFC)
Note that llvm::support::endianness has been renamed to llvm::endianness while becoming an enum class as opposed to an enum. This patch replaces suppo
Use llvm::endianness::{big,little,native} (NFC)
Note that llvm::support::endianness has been renamed to llvm::endianness while becoming an enum class as opposed to an enum. This patch replaces support::{big,little,native} with llvm::endianness::{big,little,native}.
show more ...
|
#
6b31b026 |
| 05-Oct-2023 |
Kazu Hirata <kazu@google.com> |
[Support] Deprecate system_endianness (#68279)
system_endianness() just returns llvm::endianness::native, a
compile-time constant equivalent to std::native in C++20. This patch
deprecates system_
[Support] Deprecate system_endianness (#68279)
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}.
show more ...
|
Revision tags: llvmorg-17.0.2 |
|
#
95f4b2a7 |
| 01-Oct-2023 |
Kazu Hirata <kazu@google.com> |
[GSYM] Fix the initialization of DataExtractor (#67904)
Without this patch, we pass Endian as one of the parameters to the
constructor of DataExtractor. The problem is that Endian is of:
enum
[GSYM] Fix the initialization of DataExtractor (#67904)
Without this patch, we pass Endian as one of the parameters to the
constructor of DataExtractor. The problem is that Endian is of:
enum endianness {big, little, native};
whereas the constructor is expecting "bool IsLittleEndian". That is,
we are relying on an implicit conversion to convert big and little to
false and true, respectively.
When we migrate llvm::support::endianness to std::endian in future, we
can no longer rely on an implicit conversion because std::endian is
declared with "enum class". Even if we could, the conversion would
not be guaranteed to work because, for example, libcxx defines:
enum class endian {
little = 0xDEAD,
big = 0xFACE,
:
where big and little are not boolean values.
This patch fixes the problem by properly converting Endian to a
boolean value.
show more ...
|
Revision tags: llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
89fab98e |
| 05-Dec-2022 |
Fangrui Song <i@maskray.me> |
[DebugInfo] llvm::Optional => std::optional
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
#
11011599 |
| 03-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[DebugInfo] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount
[DebugInfo] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
#
9fcd7710 |
| 28-Mar-2022 |
Kazu Hirata <kazu@google.com> |
Apply clang-tidy fixes for readability-redundant-smartptr-get in GsymReader.cpp (NFC)
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3 |
|
#
2f6cc21f |
| 20-Feb-2020 |
Greg Clayton <gclayton@fb.com> |
Add a llvm-gsymutil tool that can convert object files to GSYM and perform lookups.
Summary: This patch creates the llvm-gsymutil binary that can convert object files to GSYM using the --convert <pa
Add a llvm-gsymutil tool that can convert object files to GSYM and perform lookups.
Summary: This patch creates the llvm-gsymutil binary that can convert object files to GSYM using the --convert <path> option. It can also dump and lookup addresses within GSYM files that have been saved to disk.
To dump a file:
llvm-gsymutil /path/to/a.gsym
To perform address lookups, like with atos, on GSYM files:
llvm-gsymutil --address 0x1000 --address 0x1100 /path/to/a.gsym
To convert a mach-o or ELF file, including any DWARF debug info contained within the object files:
llvm-gsymutil --convert /path/to/a.out --out-file /path/to/a.out.gsym
Conversion highlights: - convert DWARF debug info in mach-o or ELF files to GSYM - convert symbols in symbol table to GSYM and don't convert symbols that overlap with DWARF debug info - extract UUID from object files - extract .text (read + execute) section address ranges and filter out any DWARF or symbols that don't fall in those ranges. - if .text sections are extracted, and if the last gsym::FunctionInfo object has no size, cap the size to the end of the section the function was contained in
Dumping GSYM files will dump all sections of the GSYM file in textual format.
Reviewers: labath, aadsm, serhiy.redko, jankratochvil, xiaobai, wallace, aprantl, JDevlieghere, jdoerfert
Subscribers: mgorny, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74883
show more ...
|
#
5e13e0ce |
| 16-Feb-2020 |
Greg Clayton <gclayton@fb.com> |
[NFC] Move ValidTextRanges out of DwarfTransformer and into GsymCreator and unify address is not in GSYM errors so all strings match.
|
#
22d63b63 |
| 13-Feb-2020 |
Greg Clayton <gclayton@fb.com> |
Fix buildbots by not using "and" and "not".
|
Revision tags: llvmorg-10.0.0-rc2 |
|
#
19602b71 |
| 12-Feb-2020 |
Greg Clayton <gclayton@fb.com> |
Add a DWARF transformer class that converts DWARF to GSYM.
Summary: The DWARF transformer is added as a class so it can be unit tested fully.
The DWARF is converted to GSYM format and handles many
Add a DWARF transformer class that converts DWARF to GSYM.
Summary: The DWARF transformer is added as a class so it can be unit tested fully.
The DWARF is converted to GSYM format and handles many special cases for functions: - omit functions in compile units with 4 byte addresses whose address is UINT32_MAX (dead stripped) - omit functions in compile units with 8 byte addresses whose address is UINT64_MAX (dead stripped) - omit any functions whose high PC is <= low PC (dead stripped) - StringTable builder doesn't copy strings, so we need to make backing copies of strings but only when needed. Many strings come from sections in object files and won't need to have backing copies, but some do. - When a function doesn't have a mangled name, store the fully qualified name by creating a string by traversing the parent decl context DIEs and then. If we don't do this, we end up having cases where some function might appear in the GSYM as "erase" instead of "std::vector<int>::erase". - omit any functions whose address isn't in the optional TextRanges member variable of DwarfTransformer. This allows object file to register address ranges that are known valid code ranges and can help omit functions that should have been dead stripped, but just had their low PC values set to zero. In this case we have many functions that all appear at address zero and can omit these functions by making sure they fall into good address ranges on the object file. Many compilers do this when the DWARF has a DW_AT_low_pc with a DW_FORM_addr, and a DW_AT_high_pc with a DW_FORM_data4 as the offset from the low PC. In this case the linker can't write the same address to both the high and low PC since there is only a relocation for the DW_AT_low_pc, so many linkers tend to just zero it out.
Reviewers: aprantl, dblaikie, probinson
Subscribers: mgorny, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74450
show more ...
|
#
c55cf4af |
| 10-Feb-2020 |
Bill Wendling <isanbard@gmail.com> |
Revert "Remove redundant "std::move"s in return statements"
The build failed with
error: call to deleted constructor of 'llvm::Error'
errors.
This reverts commit 1c2241a7936bf85aa68aef94bd40c3b
Revert "Remove redundant "std::move"s in return statements"
The build failed with
error: call to deleted constructor of 'llvm::Error'
errors.
This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.
show more ...
|
#
1c2241a7 |
| 10-Feb-2020 |
Bill Wendling <isanbard@gmail.com> |
Remove redundant "std::move"s in return statements
|
Revision tags: llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2 |
|
#
aeda128a |
| 04-Dec-2019 |
Greg Clayton <gclayton@fb.com> |
Add lookup functions for efficient lookups of addresses when using GsymReader classes.
Summary: Lookup functions are designed to not fully decode a FunctionInfo, LineTable or InlineInfo, they decode
Add lookup functions for efficient lookups of addresses when using GsymReader classes.
Summary: Lookup functions are designed to not fully decode a FunctionInfo, LineTable or InlineInfo, they decode only what is needed into a LookupResult object. This allows lookups to avoid costly memory allocations and avoid parsing large amounts of information one a suitable match is found.
LookupResult objects contain the address that was looked up, the concrete function address range, the name of the concrete function, and a list of source locations. One for each inline function, and one for the concrete function. This allows one address to turn into multiple frames and improves the signal you get when symbolicating addresses in GSYM files.
Reviewers: labath, aprantl
Subscribers: mgorny, hiraditya, llvm-commits, lldb-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70993
show more ...
|
Revision tags: llvmorg-9.0.1-rc1 |
|
#
cae26621 |
| 10-Oct-2019 |
Nico Weber <nicolasweber@gmx.de> |
Fix Windows build after r374381
llvm-svn: 374413
|
#
4ae13e2a |
| 10-Oct-2019 |
Greg Clayton <clayborg@gmail.com> |
Unbreak buildbots.
llvm-svn: 374410
|
#
6a2eff1e |
| 10-Oct-2019 |
Greg Clayton <clayborg@gmail.com> |
Unbreak windows buildbots.
llvm-svn: 374396
|
#
4b6c9de8 |
| 10-Oct-2019 |
Greg Clayton <clayborg@gmail.com> |
Add GsymCreator and GsymReader.
This patch adds the ability to create GSYM files with GsymCreator, and read them with GsymReader. Full testing has been added for both new classes.
This patch differ
Add GsymCreator and GsymReader.
This patch adds the ability to create GSYM files with GsymCreator, and read them with GsymReader. Full testing has been added for both new classes.
This patch differs from the original patch https://reviews.llvm.org/D53379 in that is uses a StringTableBuilder class from llvm instead of a custom version. Support for big and little endian files has been added. If the endianness matches the current host, we use efficient extraction for the header, address table and address info offset tables.
Differential Revision: https://reviews.llvm.org/D68744
llvm-svn: 374381
show more ...
|