| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lldb] Introduce SBFrameList for lazy frame iteration (#166651) This patch introduces SBFrameList, a new SBAPI class that allows iterating over stack frames lazily without calling SBThread::GetFrameAtIndex in a loop. The new SBThread::GetFrames() method returns an SBFrameList that supports Python iteration (for frame in frame_list:), indexing (frame_list[0], frame_list[-1]), and length queries (len()). The implementation uses StackFrameListSP as the opaque pointer, sharing the thread's underlying frame list to ensure frames are materialized on-demand. This is particularly useful for ScriptedFrameProviders, where user scripts will be to iterate, filter, and replace frames lazily without materializing the entire stack upfront. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> | 8 个月前 | |
[lldb] Decouple instrumentation from the reproducers Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros. Differential revision: https://reviews.llvm.org/D117712 | 4 年前 | |
[lldb] Fix SBAddressRange validation checks. (#95997) | 2 年前 | |
[lldb] Fix SBAddressRange validation checks. (#95997) | 2 年前 | |
[lldb] Remove Listener::SetShadow (#97555) It's not used since https://reviews.llvm.org/D157556. | 2 年前 | |
[lldb] Add Function::GetAddress and redirect some uses (#115836) Many calls to Function::GetAddressRange() were not interested in the range itself. Instead they wanted to find the address of the function (its entry point) or the base address for relocation of function-scoped entities (technically, the two don't need to be the same, but there's isn't good reason for them not to be). This PR creates a separate function for retrieving this, and changes the existing (non-controversial) uses to call that instead. | 1 年前 | |
Add a scripted way to re-present a stop location (#158128) This patch adds the notion of "Facade" locations which can be reported from a ScriptedResolver instead of the actual underlying breakpoint location for the breakpoint. Also add a "was_hit" method to the scripted resolver that allows the breakpoint to say which of these "Facade" locations was hit, and "get_location_description" to provide a description for the facade locations. I apologize in advance for the size of the patch. Almost all of what's here was necessary to (a) make the feature testable and (b) not break any of the current behavior. The motivation for this feature is given in the "Providing Facade Locations" section that I added to the python-reference.rst so I won't repeat it here. rdar://152112327 | 9 个月前 | |
Make SBBreakpoint/SBBreakpointLocation.SetCondition(nullptr) work again. (#162370) The addition of the StopCondition in the lldb_private layer meant that clearing a breakpoint condition with: sb_break.SetCondition(nullptr); now crashes. Also, GetCondition for an empty condition used to return a nullptr, but now it returns "". This patch fixes that crash and makes the SB GetCondition always return nullptr for an empty condition. | 9 个月前 | |
[lldb] Support specifying a language for breakpoint conditions (#147603) LLDB breakpoint conditions take an expression that's evaluated using the language of the code where the breakpoint is located. Users have asked to have an option to tell it to evaluate the expression in a specific language. This is feature is especially helpful for Swift, for example for a condition based on the value in memory at an offset from a register. Such a condition is pretty difficult to write in Swift, but easy in C. This PR adds a new argument (-Y) to specify the language of the condition expression. We can't reuse the current -L option, since you might want to break on only Swift symbols, but run a C expression there as per the example above. rdar://146119507 | 1 年前 | |
[lldb] Sink StreamFile into lldbHost StreamFile subclasses Stream (from lldbUtility) and is backed by a File (from lldbHost). It does not depend on anything from lldbCore or any of its sibling libraries, so I think it makes sense for this to live in lldbHost instead. Differential Revision: https://reviews.llvm.org/D157460 | 2 年前 | |
[lldb][NFC] Fix license comment lines that are too long These get wrapped by clang-format currently. | 2 年前 | |
[lldb][NFCI] Change type of Broadcaster's name Broadcasters don't need their names in the StringPool. It doesn't benefit from fast comparisons and doesn't benefit from uniqueness. Differential Revision: https://reviews.llvm.org/D152220 | 3 年前 | |
[lldb] Correct style of error messages (#156774) The LLVM Style Guide says the following about error and warning messages [1]: > [T]o match error message styles commonly produced by other tools, > start the first sentence with a lowercase letter, and finish the last > sentence without a period, if it would end in one otherwise. I often provide this feedback during code review, but we still have a bunch of places where we have inconsistent error message, which bothers me as a user. This PR identifies a handful of those places and updates the messages to be consistent. [1] https://llvm.org/docs/CodingStandards.html#error-and-warning-messages | 10 个月前 | |
Add AllowRepeats to SBCommandInterpreterRunOptions. (#94786) This is useful if you have a transcript of a user session and want to rerun those commands with RunCommandInterpreter. The same functionality is also useful in testing. I'm adding it primarily for the second reason. In a subsequent patch, I'm adding the ability to Python based commands to provide their "auto-repeat" command. Among other things, that will allow potentially state destroying user commands to prevent auto-repeat. Testing this with Shell or pexpect tests is not nearly as accurate or convenient as using RunCommandInterpreter, but to use that I need to allow auto-repeat. I think for consistency's sake, having interactive sessions always do auto-repeats is the right choice, though that's a lightly held opinion... | 2 年前 | |
[lldb] Ensure FILE* access mode is correctly specified when creating a NativeFile. (#167764) If we open a NativeFile with a FILE*, the OpenOptions default to eOpenOptionReadOnly. This is an issue in python scripts if you try to write to one of the files like print("Hi", file=lldb.debugger.GetOutputFileHandle()). To address this, we need to specify the access mode whenever we create a NativeFile from a FILE*. I also added an assert on the NativeFile that validates the file is opened with the correct access mode and updated NativeFile::Read and NativeFile::Write to check the access mode. Before these changes: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") Traceback (most recent call last): File "<input>", line 1, in <module> io.UnsupportedOperation: not writable After: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") abc3 Fixes #122387 | 8 个月前 | |
[lldb][nfc] Move broadcaster class strings away from ConstString (#89690) These are hardcoded strings that are already present in the data section of the binary, no need to immediately place them in the ConstString StringPools. Lots of code still calls GetBroadcasterClass and places the return value into a ConstString. Changing that would be a good follow-up. Additionally, calls to these functions are still wrapped in ConstStrings at the SBAPI layer. This is because we must guarantee the lifetime of all strings handed out publicly. | 2 年前 | |
Add support for inline DWARF source files. (#75880) LLVM supports DWARF 5 linetable extension to store source files inline in DWARF. This is particularly useful for compiler-generated source code. This implementation tries to materialize them as temporary files lazily, so SBAPI clients don't need to be aware of them. rdar://110926168 | 2 年前 | |
[lldb] Guarantee the lifetimes of all strings returned from SBAPI LLDB should guarantee that the strings returned by SBAPI methods live forever. I went through every method that returns a string and made sure that it was added to the ConstString StringPool before returning if it wasn't obvious that it was already doing so. I've also updated the docs to document this behavior. Differential Revision: https://reviews.llvm.org/D150804 | 3 年前 | |
[lldb] Ensure FILE* access mode is correctly specified when creating a NativeFile. (#167764) If we open a NativeFile with a FILE*, the OpenOptions default to eOpenOptionReadOnly. This is an issue in python scripts if you try to write to one of the files like print("Hi", file=lldb.debugger.GetOutputFileHandle()). To address this, we need to specify the access mode whenever we create a NativeFile from a FILE*. I also added an assert on the NativeFile that validates the file is opened with the correct access mode and updated NativeFile::Read and NativeFile::Write to check the access mode. Before these changes: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") Traceback (most recent call last): File "<input>", line 1, in <module> io.UnsupportedOperation: not writable After: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") abc3 Fixes #122387 | 8 个月前 | |
[lldb] Decouple instrumentation from the reproducers Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros. Differential revision: https://reviews.llvm.org/D117712 | 4 年前 | |
[lldb] Decouple instrumentation from the reproducers Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros. Differential revision: https://reviews.llvm.org/D117712 | 4 年前 | |
[lldb] Expose structured errors in SBError (#120784) Building on top of previous work that exposed expression diagnostics via SBCommandReturnObject, this patch generalizes the support to expose any SBError as machine-readable structured data. One use-case of this is to allow IDEs to better visualize expression diagnostics. rdar://139997604 | 1 年前 | |
[lldb][nfc] Move broadcaster class strings away from ConstString (#89690) These are hardcoded strings that are already present in the data section of the binary, no need to immediately place them in the ConstString StringPools. Lots of code still calls GetBroadcasterClass and places the return value into a ConstString. Changing that would be a good follow-up. Additionally, calls to these functions are still wrapped in ConstStrings at the SBAPI layer. This is because we must guarantee the lifetime of all strings handed out publicly. | 2 年前 | |
[lldb] Decouple instrumentation from the reproducers Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros. Differential revision: https://reviews.llvm.org/D117712 | 4 年前 | |
[lldb] Namespace SBSourceLanguageName (NFC) | 2 年前 | |
[lldb] Ensure FILE* access mode is correctly specified when creating a NativeFile. (#167764) If we open a NativeFile with a FILE*, the OpenOptions default to eOpenOptionReadOnly. This is an issue in python scripts if you try to write to one of the files like print("Hi", file=lldb.debugger.GetOutputFileHandle()). To address this, we need to specify the access mode whenever we create a NativeFile from a FILE*. I also added an assert on the NativeFile that validates the file is opened with the correct access mode and updated NativeFile::Read and NativeFile::Write to check the access mode. Before these changes: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") Traceback (most recent call last): File "<input>", line 1, in <module> io.UnsupportedOperation: not writable After: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") abc3 Fixes #122387 | 8 个月前 | |
Revert "[lldb] Refactor SBFileSpec::GetDirectory" This reverts commit 2bea2d7b070dc5df723ce2b92dbc654b8bb1847e. It introduced following failures on buildbot lldb-aarch64-windows: lldb-api :: functionalities/process_save_core/TestProcessSaveCore.py lldb-api :: python_api/symbol-context/TestSymbolContext.py Differential Revision: https://reviews.llvm.org/D149625 | 3 年前 | |
[lldb] Move Core/FileSpecList -> Utility/FileSpecList (NFC) There's no reason for FileSpecList to live in lldb/Core while FileSpec lives in lldb/Utility. Move FileSpecList next to FileSpec. | 3 年前 | |
[lldb] Make deep copies of Status explicit (NFC) (#107170) | 1 年前 | |
[lldb] Track CFA pointer metadata in StackID (#157498) [lldb] Track CFA pointer metadata in StackID In this commit: 9c8e71644227 [lldb] Make StackID call Fix{Code,Data} pointers (#152796) We made StackID keep track of the CFA without any pointer metadata in it. This is necessary when comparing two StackIDs to determine which one is "younger". However, the CFA inside StackIDs is also used in other contexts through the method StackID::GetCallFrameAddress. One notable case is DWARFExpression: the computation of DW_OP_call_frame_address is done using StackID. This feeds into many other places, e.g. expression evaluation may require the address of a variable that is computed from the CFA; to access the variable without faulting, we may need to preserve the pointer metadata. As such, StackID must be able to provide both versions of the CFA. In the spirit of allowing consumers of pointers to decide what to do with pointer metadata, this patch changes StackID to store both versions of the cfa pointer. Two getter methods are provided, and all call sites except DWARFExpression preserve their existing behavior (stripped pointer). Other alternatives were considered: * Just store the raw pointer. This would require changing the comparisong operator < to also receive a Process, as the comparison requires stripped pointers. It wasn't clear if all call-sites had a non-null process, whereas we know we have a process when creating a StackID. * Store a weak pointer to the process inside the class, and then strip metadata as needed. This would require a weak_ptr::lock in many operations of LLDB, and it felt wasteful. It also prevents stripping of the pointer if the process has gone away. This patch also changes RegisterContextUnwind::ReadFrameAddress, which is the method computing the CFA fed into StackID, to also preserve the signature pointers. | 10 个月前 | |
[lldb] Introduce SBFrameList for lazy frame iteration (#166651) This patch introduces SBFrameList, a new SBAPI class that allows iterating over stack frames lazily without calling SBThread::GetFrameAtIndex in a loop. The new SBThread::GetFrames() method returns an SBFrameList that supports Python iteration (for frame in frame_list:), indexing (frame_list[0], frame_list[-1]), and length queries (len()). The implementation uses StackFrameListSP as the opaque pointer, sharing the thread's underlying frame list to ensure frames are materialized on-demand. This is particularly useful for ScriptedFrameProviders, where user scripts will be to iterate, filter, and replace frames lazily without materializing the entire stack upfront. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> | 8 个月前 | |
[lldb] Add SBFunction::GetBaseName() & SBSymbol::GetBaseName() (#155939) When you are trying for instance to set a breakpoint on a function by name, but the SBFunction or SBSymbol are returning demangled names with argument lists, that match can be tedious to do. Internally, the base name of a symbol is something we handle all the time, so it's reasonable that there should be a way to get that info from the API as well. rdar://159318791 | 11 个月前 | |
[lldb] Adjust ProtocolServer connection defaults. (#155714) This adjusts the ProtocolServer command to default to create a new connection listening on localhost:0 and adds a new ServerMetadata details to ~/.lldb/mcp/lldb-<pid>.json to record information about the current MCP server. This can be consumed by the lldb-mcp binary to establish a connection from an LLM client. --------- Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com> | 11 个月前 | |
[lldb] Ensure FILE* access mode is correctly specified when creating a NativeFile. (#167764) If we open a NativeFile with a FILE*, the OpenOptions default to eOpenOptionReadOnly. This is an issue in python scripts if you try to write to one of the files like print("Hi", file=lldb.debugger.GetOutputFileHandle()). To address this, we need to specify the access mode whenever we create a NativeFile from a FILE*. I also added an assert on the NativeFile that validates the file is opened with the correct access mode and updated NativeFile::Read and NativeFile::Write to check the access mode. Before these changes: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") Traceback (most recent call last): File "<input>", line 1, in <module> io.UnsupportedOperation: not writable After: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") abc3 Fixes #122387 | 8 个月前 | |
[lldb-dap] Show load addresses in disassembly (#136755) Improves the lldb-dap disassembly by showing load addresses in disassembly, same as in a regular LLDB disassemble command by default. Before:  After:  | 1 年前 | |
[lldb-dap] Support throw and catch exception breakpoints for dynamica… (#97871) …lly registered languages First of all, this is done to support exceptions for the Mojo language, but it's done in a way that will benefit any other plugin language. 1. I added a new lldb-dap CLI argument (not DAP field) called pre-init-commands. These commands are executed before DAP initialization. The other init-commands are executed after DAP initialization. It's worth mentioning that the debug adapter returns to VSCode the list of supported exception breakpoints during DAP initialization, which means that I need to register the Mojo plugin before that initialization step, hence the need for pre-init-commands. In general, language plugins should be registered in that step, as they affect the capabilities of the debugger. 2. I added a set of APIs for lldb-dap to query information of each language related to exception breakpoints. E.g. whether a language supports throw or catch breakpoints, how the throw keyword is called in each particular language, etc. 3. I'm realizing that the Swift support for exception breakpoints in lldb-dap should have been implemented in this way, instead of hardcoding it. | 2 年前 | |
[lldb] Remove Listener::SetShadow (#97555) It's not used since https://reviews.llvm.org/D157556. | 2 年前 | |
[lldb] fix set SBLineEntryColumn (#130435) Calling the public API SBLineEntry::SetColumn() sets the row instead of the column. This probably should be backported as it has been since version 3.4. --------- Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com> | 1 年前 | |
[lldb] 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 | 3 年前 | |
[lldb] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. 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 | 3 年前 | |
[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB Applied modernize-use-equals-default clang-tidy check over LLDB. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121844 | 4 年前 | |
[lldb] Enable locate module callback for all module loading (#160199) Main executables were bypassing the locate module callback that shared libraries use, preventing custom symbol file location logic from working consistently. This PR fix this by * Adding target context to ModuleSpec * Leveraging that context to use target search path and platform's locate module callback in ModuleList::GetSharedModule This ensures both main executables and shared libraries get the same callback treatment for symbol file resolution. --------- Co-authored-by: George Hu <hyubo@meta.com> Co-authored-by: George Hu <georgehuyubo@gmail.com> | 8 个月前 | |
[lldb] Enable locate module callback for all module loading (#160199) Main executables were bypassing the locate module callback that shared libraries use, preventing custom symbol file location logic from working consistently. This PR fix this by * Adding target context to ModuleSpec * Leveraging that context to use target search path and platform's locate module callback in ModuleList::GetSharedModule This ensures both main executables and shared libraries get the same callback treatment for symbol file resolution. --------- Co-authored-by: George Hu <hyubo@meta.com> Co-authored-by: George Hu <georgehuyubo@gmail.com> | 8 个月前 | |
[lldb] Add try_lock to SBMutex (#164109) Add try_lock to confirm to Lockable, which is necessary to use it with std::scoped_lock. | 9 个月前 | |
[lldb-dap] Send a 'process' event on restart. (#163833) When we restart a process, send an updated 'process' event describing the newly launched process. I also updated the isLocalProcess value based on if we're on the 'host' platform or not. | 9 个月前 | |
[lldb] Ensure FILE* access mode is correctly specified when creating a NativeFile. (#167764) If we open a NativeFile with a FILE*, the OpenOptions default to eOpenOptionReadOnly. This is an issue in python scripts if you try to write to one of the files like print("Hi", file=lldb.debugger.GetOutputFileHandle()). To address this, we need to specify the access mode whenever we create a NativeFile from a FILE*. I also added an assert on the NativeFile that validates the file is opened with the correct access mode and updated NativeFile::Read and NativeFile::Write to check the access mode. Before these changes: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") Traceback (most recent call last): File "<input>", line 1, in <module> io.UnsupportedOperation: not writable After: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") abc3 Fixes #122387 | 8 个月前 | |
[lldb] Guarantee the lifetimes of all strings returned from SBAPI LLDB should guarantee that the strings returned by SBAPI methods live forever. I went through every method that returns a string and made sure that it was added to the ConstString StringPool before returning if it wasn't obvious that it was already doing so. I've also updated the docs to document this behavior. Differential Revision: https://reviews.llvm.org/D150804 | 3 年前 | |
[lldb] Expose SBPlatform::GetAllProcesses to the SB API (#68378) Add the ability to list all processes through the SB API. rdar://116188959 | 2 年前 | |
[LLDB][SBProgress] Add a finalize method (#128966) This patch adds a finalize method which destroys the underlying RAII SBProgress. My primary motivation for this is so I can write better tests that are non-flaky, but after discussing with @clayborg in my DAP message improvement patch (#124648) this is probably an essential API despite that I originally argued it wasn't. | 1 年前 | |
[lldb] Guarantee the lifetimes of all strings returned from SBAPI LLDB should guarantee that the strings returned by SBAPI methods live forever. I went through every method that returns a string and made sure that it was added to the ConstString StringPool before returning if it wasn't obvious that it was already doing so. I've also updated the docs to document this behavior. Differential Revision: https://reviews.llvm.org/D150804 | 3 年前 | |
[lldb] Decouple instrumentation from the reproducers Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros. Differential revision: https://reviews.llvm.org/D117712 | 4 年前 | |
[lldb] Remove vestigial remnants of reproducers (#135361) Not touching the SB API. | 1 年前 | |
[LLDB] Fix Memory64 BaseRVA, move all non-stack memory to Mem64. (#146777) ### Context Over a year ago, I landed support for 64b Memory ranges in Minidump (#95312). In this patch we added the Memory64 list stream, which is effectively a Linked List on disk. The layout is a sixteen byte header and then however many Memory descriptors. ### The Bug This is a classic off-by one error, where I added 8 bytes instead of 16 for the header. This caused the first region to start 8 bytes before the correct RVA, thus shifting all memory reads by 8 bytes. We are correctly writing all the regions to disk correctly, with no physical corruption but the RVA is defined wrong, meaning we were incorrectly reading memory  ### Why wasn't this caught? One problem we've had is forcing Minidump to actually use the 64b mode, it would be a massive waste of resources to have a test that actually wrote >4.2gb of IO to validate the 64b regions, and so almost all validation has been manual. As a weakness of manual testing, this issue is psuedo non-deterministic, as what regions end up in 64b or 32b is handled greedily and iterated in the order it's laid out in /proc/pid/maps. We often validated 64b was written correctly by hexdumping the Minidump itself, which was not corrupted (other than the BaseRVA)  ### Why is this showing up now? During internal usage, we had a bug report that the Minidump wasn't displaying values. I was unable to repro the issue, but during my investigation I saw the variables were in the 64b regions which resulted in me identifying the bug. ### How do we prevent future regressions? To prevent regressions, and honestly to save my sanity for figuring out where 8 bytes magically came from, I've added a new API to SBSaveCoreOptions. SBSaveCoreOptions::GetMemoryRegionsToSave() The ability to get the memory regions that we intend to include in the Coredump. I added this so we can compare what we intended to include versus what was actually included. Traditionally we've always had issues comparing regions because Minidump includes /proc/pid/maps and it can be difficult to know what memoryregion read failure was a genuine error or just a page that wasn't meant to be included. We are also leveraging this API to choose the memory regions to be generated, as well as for testing what regions should be bytewise 1:1. After much debate with @clayborg, I've moved all non-stack memory to the Memory64 List. This list doesn't incur us any meaningful overhead and Greg originally suggested doing this in the original 64b PR. This also means we're exercising the 64b path every single time we save a Minidump, preventing regressions on this feature from slipping through testing in the future. Snippet produced by [minidump.py](https://github.com/clayborg/scripts) MINIDUMP_MEMORY_LIST: NumberOfMemoryRanges = 0x00000002 MemoryRanges[0] = [0x00007f61085ff9f0 - 0x00007f6108601000) @ 0x0003f655 MemoryRanges[1] = [0x00007ffe47e50910 - 0x00007ffe47e52000) @ 0x00040c65 MINIDUMP_MEMORY64_LIST: NumberOfMemoryRanges = 0x000000000000002e BaseRva = 0x0000000000042669 MemoryRanges[0] = [0x00005584162d8000 - 0x00005584162d9000) MemoryRanges[1] = [0x00005584162d9000 - 0x00005584162db000) MemoryRanges[2] = [0x00005584162db000 - 0x00005584162dd000) MemoryRanges[3] = [0x00005584162dd000 - 0x00005584162ff000) MemoryRanges[4] = [0x00007f6100000000 - 0x00007f6100021000) MemoryRanges[5] = [0x00007f6108800000 - 0x00007f6108828000) MemoryRanges[6] = [0x00007f6108828000 - 0x00007f610899d000) MemoryRanges[7] = [0x00007f610899d000 - 0x00007f61089f9000) MemoryRanges[8] = [0x00007f61089f9000 - 0x00007f6108a08000) MemoryRanges[9] = [0x00007f6108bf5000 - 0x00007f6108bf7000) ### Misc As a part of this fix I had to look at LLDB logs a lot, you'll notice I added 0x to many of the PRIx64 LLDB_LOGF. This is so the user (or I) can directly copy paste the address in the logs instead of adding the hex prefix themselves. Added some SBSaveCore tests for the new GetMemoryAPI, and Docstrings. CC: @DavidSpickett, @da-viper @labath because we've been working together on save-core plugins, review it optional and I didn't tag you but figured you'd want to know | 1 年前 | |
[lldb] Convert script native types to StructuredData counterpart This patch adds the ability to pass native types from the script interpreter to methods that use a {SB,}StructuredData argument. To do so, this patch changes the ScriptedObject struture that holds the pointer to the script object as well as the originating script interpreter language. It also exposes that to the SB API via a new class called SBScriptObject. This structure allows the debugger to parse the script object and convert it to a StructuredData object. If the type is not compatible with the StructuredData types, we will store its pointer in a StructuredData::Generic object. This patch also adds some SWIG typemaps that checks the input argument to ensure it's either an SBStructuredData object, in which case it just passes it throught, or a python object that is NOT another SB type, to provide some guardrails for the user. rdar://111467140 Differential Revision: https://reviews.llvm.org/D155161 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> | 2 年前 | |
Revert "Revert "[lldb] Make SBSection::GetSectionData call Section::GetSectionData."" This reverts commit e1bbe50f5a48e9b5407de9e5f4ab8197dedc85c5. Differential Revision: https://reviews.llvm.org/D142672 | 3 年前 | |
[lldb] Deal with SupportFiles in SourceManager (NFC) (#106740) To support detecting MD5 checksum mismatches, deal with SupportFiles rather than a plain FileSpecs in the SourceManager. | 1 年前 | |
[lldb] Add/change options in statistics dump to control what sections are dumped (#95075) # Added/changed options The following options are **added** to the statistics dump command: * --targets=bool: Boolean. Dumps the targets section. * --modules=bool: Boolean. Dumps the modules section. When both options are given, the field moduleIdentifiers will be dumped for each target in the targets section. The following options are **changed**: * --transcript=bool: Changed to a boolean. Dumps the transcript section. # Behavior of statistics dump with various options The behavior is **backward compatible**: - When no options are provided, statistics dump dumps all sections. - When --summary is provided, only dumps the summary info. **New** behavior: - --targets=bool, --modules=bool, --transcript=bool overrides the above "default". For **example**: - statistics dump --modules=false dumps summary + targets + transcript. No modules. - statistics dump --summary --targets=true --transcript=true dumps summary + targets (in summary mode) + transcript. # Added options into public API In SBStatisticsOptions, add: * Set/GetIncludeTargets * Set/GetIncludeModules * Set/GetIncludeTranscript **Alternative considered**: Thought about adding Set/GetIncludeSections(string sections_spec), which receives a comma-separated list of section names to be included ("targets", "modules", "transcript"). The **benefit** of this approach is that the API is more future-proof when it comes to possible adding/changing of section names. **However**, I feel the section names are likely to remain unchanged for a while - it's not like we plan to make big changes to the output of statistics dump any time soon. The **downsides** of this approach are: 1\ the readability of the API is worse (requires reading doc to understand what string can be accepted), 2\ string input are more prone to human error (e.g. typo "target" instead of expected "targets"). # Tests bin/llvm-lit -sv ../external/llvm-project/lldb/test/API/commands/statistics/basic/TestStats.py ./tools/lldb/unittests/Interpreter/InterpreterTests New test cases have been added to verify: * Different sections are dumped/not dumped when different StatisticsOptions are given through command line (CLI or HandleCommand; see test_sections_existence_through_command) or API (see test_sections_existence_through_api). * The order in which the options are given in command line does not matter (see test_order_of_options_do_not_matter). --------- Co-authored-by: Roy Shi <royshi@meta.com> | 2 年前 | |
[lldb] Ensure FILE* access mode is correctly specified when creating a NativeFile. (#167764) If we open a NativeFile with a FILE*, the OpenOptions default to eOpenOptionReadOnly. This is an issue in python scripts if you try to write to one of the files like print("Hi", file=lldb.debugger.GetOutputFileHandle()). To address this, we need to specify the access mode whenever we create a NativeFile from a FILE*. I also added an assert on the NativeFile that validates the file is opened with the correct access mode and updated NativeFile::Read and NativeFile::Write to check the access mode. Before these changes: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") Traceback (most recent call last): File "<input>", line 1, in <module> io.UnsupportedOperation: not writable After: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") abc3 Fixes #122387 | 8 个月前 | |
[lldb][NFCI] Remove unneeded temporary std::string allocations in SBAPI This uses some friend class trickery to avoid some unneeded temporary std::string allocations. Differential Revision: https://reviews.llvm.org/D155035 | 3 年前 | |
[lldb/API] Add setters to SBStructuredData (#154445) This patch adds setters to the SBStruturedData class to be able to initialize said object from the client side directly. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> | 11 个月前 | |
[lldb] Add SBFunction::GetBaseName() & SBSymbol::GetBaseName() (#155939) When you are trying for instance to set a breakpoint on a function by name, but the SBFunction or SBSymbol are returning demangled names with argument lists, that match can be tedious to do. Internally, the base name of a symbol is something we handle all the time, so it's reasonable that there should be a way to get that info from the API as well. rdar://159318791 | 11 个月前 | |
[lldb] Decouple instrumentation from the reproducers Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros. Differential revision: https://reviews.llvm.org/D117712 | 4 年前 | |
[lldb] Decouple instrumentation from the reproducers Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros. Differential revision: https://reviews.llvm.org/D117712 | 4 年前 | |
Revert "[lldb] Introduce ScriptedFrameProvider for real threads" (#167662) The new test fails on x86 and arm64 public macOS bots: 09:27:59 ====================================================================== 09:27:59 FAIL: test_append_frames (TestScriptedFrameProvider.ScriptedFrameProviderTestCase) 09:27:59 Test that we can add frames after real stack. 09:27:59 ---------------------------------------------------------------------- 09:27:59 Traceback (most recent call last): 09:27:59 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 122, in test_append_frames 09:27:59 self.assertEqual(new_frame_count, original_frame_count + 1) 09:27:59 AssertionError: 5 != 6 09:27:59 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang 09:27:59 ====================================================================== 09:27:59 FAIL: test_applies_to_thread (TestScriptedFrameProvider.ScriptedFrameProviderTestCase) 09:27:59 Test that applies_to_thread filters which threads get the provider. 09:27:59 ---------------------------------------------------------------------- 09:27:59 Traceback (most recent call last): 09:27:59 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 218, in test_applies_to_thread 09:27:59 self.assertEqual( 09:27:59 AssertionError: 5 != 1 : Thread with ID 1 should have 1 synthetic frame 09:27:59 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang 09:27:59 ====================================================================== 09:27:59 FAIL: test_prepend_frames (TestScriptedFrameProvider.ScriptedFrameProviderTestCase) 09:27:59 Test that we can add frames before real stack. 09:27:59 ---------------------------------------------------------------------- 09:27:59 Traceback (most recent call last): 09:27:59 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 84, in test_prepend_frames 09:27:59 self.assertEqual(new_frame_count, original_frame_count + 2) 09:27:59 AssertionError: 5 != 7 09:27:59 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang 09:27:59 ====================================================================== 09:27:59 FAIL: test_remove_frame_provider_by_id (TestScriptedFrameProvider.ScriptedFrameProviderTestCase) 09:27:59 Test that RemoveScriptedFrameProvider removes a specific provider by ID. 09:27:59 ---------------------------------------------------------------------- 09:27:59 Traceback (most recent call last): 09:27:59 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 272, in test_remove_frame_provider_by_id 09:27:59 self.assertEqual(thread.GetNumFrames(), 3, "Should have 3 synthetic frames") 09:27:59 AssertionError: 5 != 3 : Should have 3 synthetic frames 09:27:59 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang 09:27:59 ====================================================================== 09:27:59 FAIL: test_replace_all_frames (TestScriptedFrameProvider.ScriptedFrameProviderTestCase) 09:27:59 Test that we can replace the entire stack. 09:27:59 ---------------------------------------------------------------------- 09:27:59 Traceback (most recent call last): 09:27:59 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 41, in test_replace_all_frames 09:27:59 self.assertEqual(thread.GetNumFrames(), 3, "Should have 3 synthetic frames") 09:27:59 AssertionError: 5 != 3 : Should have 3 synthetic frames 09:27:59 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang 09:27:59 ====================================================================== 09:27:59 FAIL: test_scripted_frame_objects (TestScriptedFrameProvider.ScriptedFrameProviderTestCase) 09:27:59 Test that provider can return ScriptedFrame objects. 09:27:59 ---------------------------------------------------------------------- 09:27:59 Traceback (most recent call last): 09:27:59 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 159, in test_scripted_frame_objects 09:27:59 self.assertEqual(frame0.GetFunctionName(), "custom_scripted_frame_0") 09:27:59 AssertionError: 'thread_func(int)' != 'custom_scripted_frame_0' 09:27:59 - thread_func(int) 09:27:59 + custom_scripted_frame_0 09:27:59 09:27:59 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang 09:27:59 ---------------------------------------------------------------------- 09:27:59 Ran 6 tests in 14.242s 09:27:59 09:27:59 FAILED (failures=6) Reverts llvm/llvm-project#161870 | 8 个月前 | |
[lldb] Introduce SBFrameList for lazy frame iteration (#166651) This patch introduces SBFrameList, a new SBAPI class that allows iterating over stack frames lazily without calling SBThread::GetFrameAtIndex in a loop. The new SBThread::GetFrames() method returns an SBFrameList that supports Python iteration (for frame in frame_list:), indexing (frame_list[0], frame_list[-1]), and length queries (len()). The implementation uses StackFrameListSP as the opaque pointer, sharing the thread's underlying frame list to ensure frames are materialized on-demand. This is particularly useful for ScriptedFrameProviders, where user scripts will be to iterate, filter, and replace frames lazily without materializing the entire stack upfront. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> | 8 个月前 | |
[lldb] Decouple instrumentation from the reproducers Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros. Differential revision: https://reviews.llvm.org/D117712 | 4 年前 | |
[lldb] Expose QueueThreadPlanForStepSingleInstruction function to SBThreadPlan (#137904) Expose QueueThreadPlanForStepSingleInstruction function to SBThreadPlan | 1 年前 | |
[lldb] Turn lldb_private::Status into a value type. (#106163) This patch removes all of the Set.* methods from Status. This cleanup is part of a series of patches that make it harder use the anti-pattern of keeping a long-lives Status object around and updating it while dropping any errors it contains on the floor. This patch is largely NFC, the more interesting next steps this enables is to: 1. remove Status.Clear() 2. assert that Status::operator=() never overwrites an error 3. remove Status::operator=() Note that step (2) will bring 90% of the benefits for users, and step (3) will dramatically clean up the error handling code in various places. In the end my goal is to convert all APIs that are of the form ResultTy DoFoo(Status& error) to llvm::Expected<ResultTy> DoFoo() How to read this patch? The interesting changes are in Status.h and Status.cpp, all other changes are mostly perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git grep -l SetErrorString lldb/source) plus the occasional manual cleanup. | 1 年前 | |
[lldb] Guarantee the lifetimes of all strings returned from SBAPI LLDB should guarantee that the strings returned by SBAPI methods live forever. I went through every method that returns a string and made sure that it was added to the ConstString StringPool before returning if it wasn't obvious that it was already doing so. I've also updated the docs to document this behavior. Differential Revision: https://reviews.llvm.org/D150804 | 3 年前 | |
[lldb] Use std::make_shared where possible (NFC) (#150714) This is a continuation of 68fd102, which did the same thing but only for StopInfo. Using make_shared is both safer and more efficient: - With make_shared, the object and the control block are allocated together, which is more efficient. - With make_shared, the enable_shared_from_this base class is properly linked to the control block before the constructor finishes, so shared_from_this() will be safe to use (though still not recommended during construction). | 1 年前 | |
[lldb] Guarantee the lifetimes of all strings returned from SBAPI LLDB should guarantee that the strings returned by SBAPI methods live forever. I went through every method that returns a string and made sure that it was added to the ConstString StringPool before returning if it wasn't obvious that it was already doing so. I've also updated the docs to document this behavior. Differential Revision: https://reviews.llvm.org/D150804 | 3 年前 | |
[lldb] Decouple instrumentation from the reproducers Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros. Differential revision: https://reviews.llvm.org/D117712 | 4 年前 | |
[lldb] Use std::make_shared where possible (NFC) (#150714) This is a continuation of 68fd102, which did the same thing but only for StopInfo. Using make_shared is both safer and more efficient: - With make_shared, the object and the control block are allocated together, which is more efficient. - With make_shared, the enable_shared_from_this base class is properly linked to the control block before the constructor finishes, so shared_from_this() will be safe to use (though still not recommended during construction). | 1 年前 | |
[lldb] Replace deprecated std::unique_ptr::unique() to silence a warning with MS-STL. NFC. MS-STL warns about this with warning STL4016: std::shared_ptr::unique() is deprecated in C++17. | 2 年前 | |
[lldb] Use std::make_shared where possible (NFC) (#150714) This is a continuation of 68fd102, which did the same thing but only for StopInfo. Using make_shared is both safer and more efficient: - With make_shared, the object and the control block are allocated together, which is more efficient. - With make_shared, the enable_shared_from_this base class is properly linked to the control block before the constructor finishes, so shared_from_this() will be safe to use (though still not recommended during construction). | 1 年前 | |
[lldb][Formatters] Add --pointer-match-depth option to type summary add command. (#138209) Currently, the type T's summary formatter will be matched for T, T*, T** and so on. This is unexpected in many data formatters. Such unhandled cases could cause the data formatter to crash. An example would be the lldb's built-in data formatter for std::optional: $ cat main.cpp #include <optional> int main() { std::optional<int> o_null; auto po_null = &o_null; auto ppo_null = &po_null; auto pppo_null = &ppo_null; return 0; } $ clang++ -g main.cpp && lldb -o "b 8" -o "r" -o "v pppo_null" [lldb crash] This change adds an options --pointer-match-depth to type summary add command to allow users to specify how many layer of pointers can be dereferenced at most when matching a summary formatter of type T, as Jim suggested [here](https://github.com/llvm/llvm-project/pull/124048/#issuecomment-2611164133). By default, this option has value 1 which means summary formatter for T could also be used for T* but not T** nor beyond. This option is no-op when --skip-pointers is set as well. I didn't add such option for type synthetic add, type format add, type filter add, because it useful for those command. Instead, they all have the pointer match depth of 1. When printing a type T*, lldb never print the children of T even if there is a synthetic formatter registered for T. | 1 年前 | |
[lldb] Use std::make_shared where possible (NFC) (#150714) This is a continuation of 68fd102, which did the same thing but only for StopInfo. Using make_shared is both safer and more efficient: - With make_shared, the object and the control block are allocated together, which is more efficient. - With make_shared, the enable_shared_from_this base class is properly linked to the control block before the constructor finishes, so shared_from_this() will be safe to use (though still not recommended during construction). | 1 年前 | |
[lldb] Change UnixSignals::GetSignalAsCString to GetSignalAsStringRef This is in preparation to remove the uses of ConstString from UnixSignals. Differential Revision: https://reviews.llvm.org/D158209 | 2 年前 | |
[lldb] Use std::make_shared where possible (NFC) (#150714) This is a continuation of 68fd102, which did the same thing but only for StopInfo. Using make_shared is both safer and more efficient: - With make_shared, the object and the control block are allocated together, which is more efficient. - With make_shared, the enable_shared_from_this base class is properly linked to the control block before the constructor finishes, so shared_from_this() will be safe to use (though still not recommended during construction). | 1 年前 | |
[lldb] Move ValueObject into its own library (NFC) (#113393) ValueObject is part of lldbCore for historical reasons, but conceptually it deserves to be its own library. This does introduce a (link-time) circular dependency between lldbCore and lldbValueObject, which is unfortunate but probably unavoidable because so many things in LLDB rely on ValueObject. We already have cycles and these libraries are never built as dylibs so while this doesn't improve the situation, it also doesn't make things worse. The header includes were updated with the following command: find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \; | 1 年前 | |
[lldb] Decouple instrumentation from the reproducers Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros. Differential revision: https://reviews.llvm.org/D117712 | 4 年前 | |
[lldb] Make deep copies of Status explicit (NFC) (#107170) | 1 年前 | |
Reland "[lldb] Add 'modify' type watchpoints, make it default (#66308)" This reverts commit a7b78cac9a77e3ef6bbbd8ab1a559891dc693401. With updates to the tests. TestWatchTaggedAddress.py: Updated the expected watchpoint types, though I'm not sure there should be a differnt default for the two ways of setting them, that needs to be confirmed. TestStepOverWatchpoint.py: Skipped this everywhere because I think what used to happen is you couldn't put 2 watchpoints on the same address (after alignment). I guess that this is now allowed because modify watchpoints aren't accounted for, but likely should be. Needs investigating. | 2 年前 | |
[LLDB][NFC] Remove Debugger dependency in SystemLifetimeManager (#134383) It reduces the memory usage in lldb-server. | 1 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb/lua] Supplement Lua bindings for lldb module Add necessary typemaps for Lua bindings, together with some other files. Signed-off-by: Siger Yang <sigeryeung@gmail.com> Reviewed By: tammela Differential Revision: https://reviews.llvm.org/D108090 | 4 年前 | |
[lldb/lua] Supplement Lua bindings for lldb module Add necessary typemaps for Lua bindings, together with some other files. Signed-off-by: Siger Yang <sigeryeung@gmail.com> Reviewed By: tammela Differential Revision: https://reviews.llvm.org/D108090 | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 8 个月前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 10 个月前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 8 个月前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 8 个月前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 4 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 4 年前 |