| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 8 个月前 | ||
[lldb-dap] persistent assembly breakpoints (#148061) Resolves #141955 - Adds data to breakpoints Source object, in order for assembly breakpoints, which rely on a temporary sourceReference value, to be able to resolve in future sessions like normal path+line breakpoints - Adds optional instructions_offset parameter to BreakpointResolver | 11 个月前 | |
[lldb][gnustep] Add minimal GNUstepObjCRuntime plugin for LanguageTypeObjC on non-Apple platforms This is the next patch after D146058. We can now parse expressions to print instance variables from ObjC classes. Until now the expression parser would bail out with an error like this: error: expression failed to parse: error: Error [IRForTarget]: Couldn't find Objective-C indirect ivar symbol OBJC_IVAR_$_TestObj._int Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D146154 | 3 年前 | |
[lldb][ObjC] Consult Objective-C runtime decl vendor when completing type (#164011) (Note, this upstreams code that has been deployed on Apple's Swift LLDB for many years at this point). When a ValueObject computes its "complete type" (MaybeCalculateCompleteType), it gives the language runtimes a chance to override the type known to it. The current implementation of ObjCLanguageRuntime::GetRuntimeType, however, didn't consult the AppleObjCDeclVendor to look for types. As demonstrated in the attached test, when we don't have debug-info for a base class type (most commonly happens when inheriting from system framework types) we would not be able to deduce ivars of that type. However, the runtime knows about the ivars, so we should be able to retrieve them. There's still a couple of caveats for future follow-up/investigation: 1. frame var isn't able to access such backing ivars explicitly (even if they do exist) 2. When compiling with -gmodules, LLDB gets confused about what is correct source of information for these decls is. rdar://162069497 | 9 个月前 | |
[lldb][ObjC] Consult Objective-C runtime decl vendor when completing type (#164011) (Note, this upstreams code that has been deployed on Apple's Swift LLDB for many years at this point). When a ValueObject computes its "complete type" (MaybeCalculateCompleteType), it gives the language runtimes a chance to override the type known to it. The current implementation of ObjCLanguageRuntime::GetRuntimeType, however, didn't consult the AppleObjCDeclVendor to look for types. As demonstrated in the attached test, when we don't have debug-info for a base class type (most commonly happens when inheriting from system framework types) we would not be able to deduce ivars of that type. However, the runtime knows about the ivars, so we should be able to retrieve them. There's still a couple of caveats for future follow-up/investigation: 1. frame var isn't able to access such backing ivars explicitly (even if they do exist) 2. When compiling with -gmodules, LLDB gets confused about what is correct source of information for these decls is. rdar://162069497 | 9 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 8 个月前 | ||
| 11 个月前 | ||
| 3 年前 | ||
| 9 个月前 | ||
| 9 个月前 |