summaryrefslogtreecommitdiff
path: root/llvm/lib/XRay/InstrumentationMap.cpp
AgeCommit message (Collapse)Author
2025-06-04[llvm] Remove unused includes (NFC) (#142733)Kazu Hirata
These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures.
2024-12-10[XRay][RISCV] RISCV support for XRay (#117368)Min-Yih Hsu
Add RISC-V support for XRay. The RV64 implementation has been tested in both QEMU and in our hardware environment. Currently this requires D and C extensions, but since both RV64GC and RVA22/RVA23 are becoming mainstream, I don't think this requirement will be a big problem. Based on the previous work by @a-poduval : https://reviews.llvm.org/D117929 --------- Co-authored-by: Ashwin Poduval <ashwin.poduval@gmail.com>
2023-07-14[XRay] Add initial support for loongarch64Weining Lu
Only support patching FunctionEntry/FunctionExit/FunctionTailExit for now. Reviewed By: MaskRay, xen0n Co-Authored-By: zhanglimin <zhanglimin@loongson.cn> Differential Revision: https://reviews.llvm.org/D140727
2023-02-07[NFC][TargetParser] Remove llvm/ADT/Triple.hArchibald Elliott
I also ran `git clang-format` to get the headers in the right order for the new location, which has changed the order of other headers in two files.
2022-12-20[llvm] Use std::optional instead of OptionalKazu Hirata
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
2022-12-06[ADT] Don't including None.h (NFC)Kazu Hirata
These source files no longer use None, so they do not need to include None.h. 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
2022-12-02[llvm] Use std::nullopt instead of None (NFC)Kazu Hirata
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
2022-11-26[llvm] Use std::size (NFC)Kazu Hirata
std::size, introduced in C++17, allows us to directly obtain the number of elements of an array.
2021-10-22Support: Use Expected<T>::moveInto() in a few placesDuncan P. N. Exon Smith
These are some usage examples for `Expected<T>::moveInto()`. Differential Revision: https://reviews.llvm.org/D112280
2021-10-09Fixed some errors detected by PVS StudioDávid Bolvanský
2020-12-04[lib/Object, tools] - Make ELFObjectFile::getELFFile return reference.Georgii Rymar
We always have an object, so we don't have to return a pointer. Differential revision: https://reviews.llvm.org/D92560
2020-11-20[lib/Object] - Generalize the RelocationResolver API.Georgii Rymar
This allows to reuse the RelocationResolver from the code that doesn't want to deal with `RelocationRef` class. I am going to use it in llvm-readobj. See the description of D91530 for more details. Differential revision: https://reviews.llvm.org/D91533
2020-05-28[xray] Add llvm-xray extract support for 32 bit ARMIan Levesque
Summary: XRay works on 32-bit ARM but extract didn't support it. See also another previous attempt in D77858. Reviewers: MaskRay, dberris, johnislarry Subscribers: kristof.beyls, hiraditya, danielkiss, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80185
2020-05-28clang-format xray InstrumentationMap.cppIan Levesque
2020-05-02[Object] Change ObjectFile::getSymbolValue() return type to Expected<uint64_t>Xing GUO
Summary: In D77860, we have changed `getSymbolFlags()` return type to `Expected<uint32_t>`. This change helps bubble the error further up the stack. Reviewers: jhenderson, grimar, JDevlieghere, MaskRay Reviewed By: jhenderson Subscribers: hiraditya, MaskRay, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79075
2020-04-24[XRay] Change Sled.Function to PC-relative for sled version 2 and make ↵Fangrui Song
llvm-xray support sled version 2 addresses Follow-up of D78082 and D78590. Otherwise, because xray_instr_map is now read-only, the absolute relocation used for Sled.Function will cause a text relocation.
2020-02-10Revert "Remove redundant "std::move"s in return statements"Bill Wendling
The build failed with error: call to deleted constructor of 'llvm::Error' errors. This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.
2020-02-10Remove redundant "std::move"s in return statementsBill Wendling
2019-11-08[llvm-xray] Add AArch64 to llvm-xray extractAditya Kumar
This required adding support for resolving R_AARCH64_ABS64 relocations to get accurate addresses for function names to resolve. Authored by: ianlevesque (Ian Levesque) Reviewers: dberris, phosek, smeenai, tetsuo-cpp Differential Revision: https://reviews.llvm.org/D69967
2019-08-14Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar
Expected<>" Changes: no changes. A fix for the clang code will be landed right on top. Original commit message: SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368826
2019-08-14Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar
Expected<>" It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455 llvm-svn: 368813
2019-08-14[llvm/Object] - Convert SectionRef::getName() to return Expected<>George Rimar
SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368812
2019-08-06Switch LLVM to use 64-bit offsets (2/5)Igor Kudrin
This updates all libraries and tools in LLVM Core to use 64-bit offsets which directly or indirectly come to DataExtractor. Differential Revision: https://reviews.llvm.org/D65638 llvm-svn: 368014
2019-07-11Open native file handles to avoid converting from FDs, NFCReid Kleckner
Follow up to r365588. llvm-svn: 365820
2019-07-10[Support] Move llvm::MemoryBuffer to sys::fs::file_tReid Kleckner
Summary: On Windows, Posix integer file descriptors are a compatibility layer over native file handles provided by the C runtime. There is a hard limit on the maximum number of file descriptors that a process can open, and the limit is 8192. LLD typically doesn't run into this limit because it opens input files, maps them into memory, and then immediately closes the file descriptor. This prevents it from running out of FDs. For various reasons, I'd like to open handles to every input file and keep them open during linking. That requires migrating MemoryBuffer over to taking open native file handles instead of integer FDs. Reviewers: aganea, Bigcheese Reviewed By: aganea Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner Tags: #llvm Differential Revision: https://reviews.llvm.org/D63453 llvm-svn: 365588
2019-05-16Recommit [Object] Change object::SectionRef::getContents() to return ↵Fangrui Song
Expected<StringRef> r360876 didn't fix 2 call sites in clang. Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360892
2019-05-16Revert r360876 "[Object] Change object::SectionRef::getContents() to return ↵Hans Wennborg
Expected<StringRef>" It broke the Clang build, see llvm-commits thread. > Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. > > Follow-up of D61781. llvm-svn: 360878
2019-05-16[Object] Change object::SectionRef::getContents() to return Expected<StringRef>Fangrui Song
Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360876
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-12-14[Object] Rename getRelrRelocationType to getRelativeRelocationTypeFangrui Song
Summary: The two utility functions were added in D47919 to support SHT_RELR. However, these are just relative relocations types and are't necessarily be named Relr. Reviewers: phosek, dberris Reviewed By: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D55691 llvm-svn: 349133
2018-12-14[llvm-xray] Use correct variable namePetr Hosek
This fixes the compiler error introduced in r349129. llvm-svn: 349130
2018-12-14[llvm-xray] Store offset pointers in temporariesPetr Hosek
DataExtractor::getU64 modifies the OffsetPtr which also pass to RelocateOrElse which breaks on Windows. This addresses the issue introduced in r349120. Differential Revision: https://reviews.llvm.org/D55689 llvm-svn: 349129
2018-12-14[llvm-xray] Support for PIEPetr Hosek
When the instrumented binary is linked as PIE, we need to apply the relative relocations to sleds. This is handled by the dynamic linker at runtime, but when processing the file we have to do it ourselves. Differential Revision: https://reviews.llvm.org/D55542 llvm-svn: 349120
2018-09-10[Xray] tooling allow MachO format supportDavid Carlier
Getting writable xray __DATA sections from MachO as well. Reviewers: dberris Reviewed By: dberris Differential Revision: https://reviews.llvm.org/D51758 llvm-svn: 341772
2017-08-21[XRay][tools] Support new kinds of instrumentation map entriesDean Michael Berris
Summary: When extracting the instrumentation map from a binary, we should be able to recognize the new kinds of instrumentation sleds we've been emitting with the compiler using -fxray-instrument. This change adds a test for all the kinds of sleds we currently support (sans the tail-call sled, which is a bit harder to force in a simple prebuilt input). Reviewers: kpw, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36819 llvm-svn: 311305
2017-06-06Sort the remaining #include lines in include/... and lib/....Chandler Carruth
I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
2017-02-10[XRay] Implement powerpc64le xray.Tim Shen
Summary: powerpc64 big-endian is not supported, but I believe that most logic can be shared, except for xray_powerpc64.cc. Also add a function InvalidateInstructionCache to xray_util.h, which is copied from llvm/Support/Memory.cpp. I'm not sure if I need to add a unittest, and I don't know how. Reviewers: dberris, echristo, iteratee, kbarton, hfinkel Subscribers: mehdi_amini, nemanjai, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D29742 llvm-svn: 294781
2017-02-09[MC] Fix some Clang-tidy modernize and Include What You Use warnings in ↵Eugene Zelenko
SubtargetFeature; other minor fixes (NFC). Same changes in files affected by reduced SubtargetFeature.h dependencies. llvm-svn: 294548
2017-02-01[XRay] Define the InstrumentationMap typeDean Michael Berris
Summary: This change implements the instrumentation map loading library which can understand both YAML-defined instrumentation maps, and ELF 64-bit object files that have the XRay instrumentation map section. We break it out into a library on its own to allow for other applications to deal with the XRay instrumentation map defined in XRay-instrumented binaries. This type provides both raw access to the logical representation of the instrumentation map entries as well as higher level functions for converting a function ID into a function address. At this point we only support ELF64 binaries and YAML-defined XRay instrumentation maps. Future changes should extend this to support 32-bit ELF binaries, as well as other binary formats (like MachO). As part of this change we also migrate all uses of the extraction logic that used to be defined in tools/llvm-xray/ to use this new type and interface for loading from files. We also remove the flag from the `llvm-xray` tool that required users to specify the type of the instrumentation map file being provided to instead make the library auto-detect the file type. Reviewers: dblaikie Subscribers: mgorny, varno, llvm-commits Differential Revision: https://reviews.llvm.org/D29319 llvm-svn: 293721
generated by cgit v1.2.3 (git 2.25.1) at 2026-10-24 09:31:23 +0000