summaryrefslogtreecommitdiff
path: root/lldb/test/Shell/SymbolFile/PDB/function-nested-block.test
AgeCommit message (Collapse)Author
2025-10-28[LLDB][PDB] Run `function-nested-block.test` with both plugins (#165364)nerix
This test passes with both plugins, but only ran with the DIA plugin. It was fixed with #161678, where I missed this test.
2025-10-07Reland "[LLDB][NativePDB] Create functions with mangled name" (#161678)nerix
Relands #149701 which was reverted in https://github.com/llvm/llvm-project/commit/185ae5cdc695248b58ae017508cc764c19bee5b7 because it broke demangling of Itanium symbols on i386. The last commit in this PR adds the fix for this (discussed in #160930). On x86 environments, the prefix of `__cdecl` functions will now be removed to match DWARF. I opened #161676 to discuss this for the other calling conventions.
2025-09-25Revert "[LLDB][NativePDB] Create functions with mangled name (#149701)"Martin Storsjö
This reverts commit e98f34eb08b2bf7aed787e7f8a7cea9111f044c8. This broke demangling of Itanium symbols on i386.
2025-09-24[LLDB][NativePDB] Create functions with mangled name (#149701)nerix
Before, functions created using the NativePDB plugin would not know about their mangled name. This showed when printing a stacktrace. There, only the function name was shown. For https://github.com/llvm/llvm-project/issues/143149, the mangled function name is required to separate different parts. This PR adds that name if available. The Clang AST nodes also take in a mangled name, which was previously unset. I don't think this unblocks anything further, because Clang can mangle the function anyway.
2024-12-03Reapply "[lldb] Use the function block as a source for function ranges ↵Pavel Labath
(#117996)" This reverts commit 2526d5b1689389da9b194b5ec2878cfb2f4aca93, reapplying ba14dac481564000339ba22ab867617590184f4c after fixing the conflict with #117532. The change is that Function::GetAddressRanges now recomputes the returned value instead of returning the member. This means it now returns a value instead of a reference type.
2024-12-03Revert "[lldb] Use the function block as a source for function ranges (#117996)"Pavel Labath
This reverts commit ba14dac481564000339ba22ab867617590184f4c. I guess "has no conflicts" doesn't mean "it will build".
2024-12-03[lldb] Use the function block as a source for function ranges (#117996)Pavel Labath
This is a follow-up/reimplementation of #115730. While working on that patch, I did not realize that the correct (discontinuous) set of ranges is already stored in the block representing the whole function. The catch -- ranges for this block are only set later, when parsing all of the blocks of the function. This patch changes that by populating the function block ranges eagerly -- from within the Function constructor. This also necessitates a corresponding change in all of the symbol files -- so that they stop populating the ranges of that block. This allows us to avoid some unnecessary work (not parsing the function DW_AT_ranges twice) and also results in some simplification of the parsing code.
2023-05-16Emit the correct flags for the PROC CodeView Debug SymbolDaniel Paoliello
The S_LPROC32_ID and S_GPROC32_ID CodeView Debug Symbols have a flags field which LLVM has had the values for (in the ProcSymFlags enum) but has never actually set. These flags are used by Microsoft-internal tooling that leverages debug information to do binary analysis. Modified LLVM to set the correct flags: - ProcSymFlags::HasOptimizedDebugInfo - always set, as this indicates that debug info is present for optimized builds (if debug info is not emitted for optimized builds, then LLVM won't emit a debug symbol at all). - ProcSymFlags::IsNoReturn and ProcSymFlags::IsNoInline - set if the function has the NoReturn or NoInline attributes respectively. - ProcSymFlags::HasFP - set if the function requires a frame pointer (per TargetFrameLowering::hasFP). Per discussion in review, XFAIL'ing lldb test until someone working on lldb has a chance to look at it. Differential Revision: https://reviews.llvm.org/D148761
2019-10-09Re-land "[test] Split LLDB tests into API, Shell & Unit"Jonas Devlieghere
The original patch got reverted because it broke `check-lldb` on a clean build. This fixes that. llvm-svn: 374201
2019-10-09Revert [test] Split LLDB tests into API, Shell & UnitAdrian Prantl
as it appears to have broken check-lldb. This reverts r374184 (git commit 22314179f0660c172514b397060fd8f34b586e82) llvm-svn: 374187
2019-10-09[test] Split LLDB tests into API, Shell & UnitJonas Devlieghere
LLDB has three major testing strategies: unit tests, tests that exercise the SB API though dotest.py and what we currently call lit tests. The later is rather confusing as we're now using lit as the driver for all three types of tests. As most of this grew organically, the directory structure in the LLDB repository doesn't really make this clear. The 'lit' tests are part of the root and among these tests there's a Unit and Suite folder for the unit and dotest-tests. This layout makes it impossible to run just the lit tests. This patch changes the directory layout to match the 3 testing strategies, each with their own directory and their own configuration file. This means there are now 3 directories under lit with 3 corresponding targets: - API (check-lldb-api): Test exercising the SB API. - Shell (check-lldb-shell): Test exercising command line utilities. - Unit (check-lldb-unit): Unit tests. Finally, there's still the `check-lldb` target that runs all three test suites. Finally, this also renames the lit folder to `test` to match the LLVM repository layout. Differential revision: https://reviews.llvm.org/D68606 llvm-svn: 374184