[lldb-dev] LLDB: Unwinding based on Assembly Instruction Profiling
Hi As far as I know, if the unwinding based on Assembly Instruction Profiling fails in LLDB then either EH frame unwinding or some other mechanism comes into picture to unwind properly. Am I right? In this case, should LLDB change the unwinder plan from Assembly Instruction Profiling to EH Frame based unwinding so that in future the unwinding is always done with the new unwind plan rather than first checking the assembly based unwind plan and then falling back to EH Frame based unwind plan? Thanks ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 25172] New: TestBatchMode is flaky on linux
https://llvm.org/bugs/show_bug.cgi?id=25172
Bug ID: 25172
Summary: TestBatchMode is flaky on linux
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
The test (very rarely) fails on the linux buildbot. The reported error is:
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/test/driver/batch_mode/TestBatchMode.py",
line 81, in batch_mode
self.expect_string("Got there on time and it did not crash.")
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/test/driver/batch_mode/TestBatchMode.py",
line 37, in expect_string
self.fail ("Got EOF waiting for '%s'"%(string))
AssertionError: Got EOF waiting for 'Got there on time and it did not crash.'
--
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 25147] remove lldb-XXXXXX.expr temporary files when we are done with them
https://llvm.org/bugs/show_bug.cgi?id=25147 lab...@google.com changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |lab...@google.com --- Comment #2 from lab...@google.com --- Thanks for the explanation. I have now figured out what was going on. On linux, the computation of the temp directory failed, which caused all of these files to be placed in /tmp (and not deleted). I'll have something up for review shortly. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [BUG?] Confusion between translation units?
Thanks for an excellent explanation.
Unfortunately, -fno-limit-debug-info did not fix the problem; and that
I don't see the problem with a gcc/gdb setup.
So what I'm doing is forward-declaring LLVM IR entities (like `Value',
`Type', `Function'), so that multiple downstream modules don't include
those LLVM headers potentially double-including global statics. I'm
trying to look inside an llvm::Function * in the debugger now, and it
fails.
I'm going to try building LLVM itself with -fno-limit-debug-info now.
Let me know if there are other things I can try.
Thanks.
Ram
On Tue, Oct 13, 2015 at 6:26 PM, Greg Clayton wrote:
> In LLDB we create clang::ASTContext objects for the modules (executable and
> shared libraries), one for the target to contain the expression results, and
> one for each expression.
>
> When we evaluate an expression we might do something like:
>
> (lldb) expr a + b
>
> where "a" is from liba.so and "b" is from libb.so. We must copy types from
> the clang::ASTContext for each module, so we will copy the type of "a" into
> the expression clang::ASTContext and we will also copy type "b" from the
> clang::ASTContext from libb.so into the expression clang::ASTContext. Many
> times we the same types, but one has more information in it. Like lets say
> both "a" and "b" are type "foo". We can often end up with different
> definitions of "foo" in liba.so and libb.so and when we try to copy the
> types, we first copy "foo" from liba.so into the expression AST, and
> then we do the same with "b" from libb.so, but it notices that the types are
> the same level, so it tries to verify the types are the same. This often
> fails due to debug info being more complete in one of the shared libraries.
> One example is the compiler might omit the complete definition for a base
> class in libb.so where it has a complete definition for the base class in
> liba.so. When parsing types we must always give clang something it is happy
> with, so if we run into debug info that has a complete definition for
> "foo", but it inherits from class "C". So the definition for "C" in
> liba.so is:
>
> class C
> {
> public:
> C();
> ~C();
> int callme();
> };
>
> and "C" in "libb.so" is just a forward declaration:
>
> class C;
>
> But then int libb.so we must create a type for foo but we can't since C
> isn't complete, but we do anyway by just saying C looks like:
>
> class C
> {
> };
>
> So now we have two types that differ, and importing both foo types into
> the expression clang::ASTContext will fail. This happens a lot for C++
> template classes because of the haphazard way that compilers generate debug
> info for templates. It could be a bug in the type importer where the two
> types are actually the same, but the type importer thinks they are different,
> but often it is because the types actually do differ.
>
> One way to get around the compiler emitting forward declarations to base
> classes is to specify: -fno-limit-debug-info
>
> This will disable the debug info minimizing feature and make the compiler
> emit more complete debug info and it might fix your problem.
>
> Greg Clayton
>
>> On Oct 13, 2015, at 10:44 AM, Ramkumar Ramachandra via lldb-dev
>> wrote:
>>
>> Hi,
>>
>> At one point in the debugging session, I get this when I try to print
>> a particular value:
>>
>> error: field '__r_' declared with incompatible types in different
>> translation units
>> ('std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >' vs.
>> 'std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >')
>> error: field '__r_' declared with incompatible types in different
>> translation units
>> ('std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >' vs.
>> 'std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >')
>> error: field '__r_' declared with incompatible types in different
>> translation units
>> ('std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >' vs.
>> 'std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >')
>> error: field '__r_' declared with incompatible types in different
>> translation units
>> ('std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >' vs.
>> 'std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >')
>> note: declared here with type
>> 'std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >'
>> note: declared here with type
>> 'std::__1::__compressed_pair> std::__1::char_traits, std::__1::allocator >::__rep,
>> std::__1::allocator >'
>> note: declared here with type
>> 'std::__1::__compressed_pair>
Re: [lldb-dev] Python 3 and dotest
On Tue, Oct 13, 2015 at 9:08 PM Todd Fiala wrote: > On Tue, Oct 13, 2015 at 9:45 AM, Zachary Turner > wrote: > >> On Mon, Oct 12, 2015 at 7:31 PM Zachary Turner >> wrote: >> >>> Moving this to the public list because it seems useful to see what other >>> members of the community have to say as well. >>> >> >> BTW , I realized I didn't give any context here and it's hard to follow a >> long quote thread. Mostly this is just to give a heads up that support for >> Python 3 in LLDB is -- at a minimum -- coming, so I want to find out who >> (if anyone) is interested in this and how people plan to use it (or not use >> it). >> >> I'm sure the first question is probably "Why are you doing this?". The >> short version is that it's quite literally the only path forward on >> Windows. There is no way to transition to the next version of the compiler >> without moving to Python 3.5 or greater. If you want the long version, let >> me know. >> >> The biggest challenge (which is what most of the quote thread is about) >> is going to be having dotest support both Python 2 and Python 3 >> simultaneously. LLDB supporting both at the native level shouldn't be a >> problem, it's mostly about writing Python code inside of dotest that works >> in both 2 and 3. >> >> This will be the first time I've tried porting a large Python codebase to >> Python 3, so I'm open for suggestions on how to minimize the impact of >> this. Currently I'm of the mind that the onus should be on the person >> checking in a test (or a change to the test suite) to make sure it works in >> both versions of Python. >> > > I'd probably throw out here that as a change is being introduced for the > benefit primarily of getting things running on the Windows side, > I actually disagree with this. Having Python 3 support in LLDB is a big win for the entire project. We all know Python 2.x is effectively dead, and the only reason anyone is still using it is for legacy support. This means that we are hindering the adoption of LLDB for anyone who doesn't have a large legacy codebase to maintain. Which, for all practical purposes, means anyone starting a new project and considering using LLDB. That's a huge negative from an open source perspective IMO. But that's just a lower bound. There are other people who are ready and willing to move to Python 3, but can't because certain tools and libraries require them to use Python 2.x. Unfortunately, LLDB is one of those tools. When changes started going into lit on the LLVM side to make it Python 3 compatible, more than one person spoke up to say that they were pleased they could finally remove Python 2 from their systems. We're also hindering those people from making contributions from LLDB. Python 3 is the future, Python 2 is the past, so supporting it is a good long term strategy. The only reason Windows should be part of the discussion at all is because it's the catalyst that makes *me* want to do the work now, instead of someone else doing the work later. Believe it or not, there are also benefits for LLDB developers not on Windows, even if they are stuck on 2.7. By moving a newer version of the compiler, we get almost 100% C++11 and C99 conformance. This opens the door for LLDB to use a lot of new language features that people have been either intentionally holding back on or forced to remove because of this one compiler. Off the top of my head, a wildly incomplete list is: constexpr, shared_mutex, complete implementation of C++ standard library, rvalue references, initializer lists, thread_local, thread-safe function local statics, compiler-agnostic __attribute__ syntax, and more. Everyone benefits from that, ironically, by supporting Python 3 > I'm not sure it's a great idea to put the onus on everyone making sure > they run in both places, at least up front. > TBH I can't think of a reasonable alternative. There's going to have to be a buildbot testing LLDB against Python 3, and that buildbot has to stay green, like all other buildbots. So any policies which apply normally to buildbots should apply to this one. We do have a special exception in LLDB specifically as it relates to OS specific differences (for example someone Linux breaks the Windows build and doesn't know how to fix it), but that case is different for two reasons. First, not everyone has access to or is an expert on every piece of hardware supported by LLDB, so it's impossible to expect they would be able to fix every change. Second, when it is not obvious from the buildbot logs what the problem is on a specific platform, a test can simply be xfailed or skipped to give the platform owner a chance to look into the cause of the failure. Neither of these holds if we're talking about the choice of scripting environment. For the first point, it *is* reasonable to expect that someone can install Python 3 on their machine. This is of course contingent on your findings about what difficulties arise with side-by-side in
Re: [lldb-dev] incorrect shared library addresses
I have the same behavior with the system lldb and the one I build in xcode. My xcode is Version 6.4 (6E35b) I just hit command-b to build, is that what you mean? I don't really know xcode very well. On Tue, Oct 13, 2015 at 10:08 PM Todd Fiala wrote: > > Breakpoint 1: where = wikilinktester`main.main + 805 at > wikilinktester.go:35, address = 0x2365 > > The address of the breakpoint is kinda interesting - that seems > suspiciously low for an OS X user executable. > > Which lldb are you using? If you built it, what process did you use to > build it, and which Xcode do you have? > > On Tue, Oct 13, 2015 at 4:25 PM, Ryan Brown via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> I'm having a strange issue debugging a go program. >> >> I set a breakpoint, and lldb stops at it. However, lldb thinks it's in a >> different function: >> (lldb) b wikilinktester.go:35 >> Breakpoint 1: where = wikilinktester`main.main + 805 at >> wikilinktester.go:35, address = 0x2365 >> (lldb) r >> Process 43141 launched: '/tmp/gopath/bin/wikilinktester' (x86_64) >> Process 43141 stopped >> * thread #5: tid = 0x0001, 0x2365 libOpenScriptingUtil.dylib, >> stop reason = breakpoint 1.1 >> frame #0: 0x2365 libOpenScriptingUtil.dylib >> -> 0x2365: movq %rax, 0x48(%rsp) >> 0x236a: movq %rax, (%rsp) >> 0x236e: callq 0xb23d0 >> 0x2373: movq 0x8(%rsp), %rbx >> >> For some reason lldb seems to think all the shared libraries are loaded >> at address 0: >> (lldb) image list >> [ 0] 0x1000 >> /tmp/gopath/bin/wikilinktester >> [ 1] B1B370A5-479F-3533-8AD7-97B687D4F989 0x7fff5fc0 >> /usr/lib/dyld >> [ 2] 1866C519-C5F3-3D09-8C17-A8F703664521 0x >> /usr/lib/libSystem.B.dylib >> [ 3] 5C0892B8-9691-341F-9279-CA3A74D59AA0 0x >> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation >> [ 4] F4FD-043A-30CA-9997-4211CA0E9297 0x >> /System/Library/Frameworks/Security.framework/Versions/A/Security >> [ 5] 45E9A2E7-99C4-36B2-BEE3-0C4E11614AD1 0x >> /usr/lib/system/libcache.dylib >> [ 6] E789748D-F9A7-3CFF-B317-90DF348B1E95 0x >> /usr/lib/system/libcommonCrypto.dylib >> [ 7] BF8FC133-EE10-3DA6-9B90-92039E28678F 0x >> /usr/lib/system/libcompiler_rt.dylib >> [ 8] 0C68D3A6-ACDD-3EF3-991A-CC82C32AB836 0x >> /usr/lib/system/libcopyfile.dylib >> [ 9] 5779FFA0-4D9A-3AD4-B7F2-618227621DC8 0x >> /usr/lib/system/libcorecrypto.dylib >> [ 10] 502CF32B-669B-3709-8862-08188225E4F0 0x >> /usr/lib/system/libdispatch.dylib >> [ 11] CFBBE540-D503-3AFC-B5D6-644F1E69949B 0x >> /usr/lib/system/libdyld.dylib >> [ 12] 77845842-DE70-3CC5-BD01-C3D14227CED5 0x >> /usr/lib/system/libkeymgr.dylib >> [ 13] 4F81CA3A-D2CE-3030-A89D-42F3DAD7BA8F 0x >> /usr/lib/system/liblaunch.dylib >> [ 14] 126CA2ED-DE91-308F-8881-B9DAEC3C63B6 0x >> /usr/lib/system/libmacho.dylib >> [ 15] 7AF90041-2768-378A-925A-D83161863642 0x >> /usr/lib/system/libquarantine.dylib >> [ 16] 3485B5F4-6CE8-3C62-8DFD-8736ED6E8531 0x >> /usr/lib/system/libremovefile.dylib >> [ 17] F153AC5B-0542-356E-88C8-20A62CA704E2 0x >> /usr/lib/system/libsystem_asl.dylib >> [ 18] 9615D10A-FCA7-3BE4-AA1A-1B195DACE1A1 0x >> /usr/lib/system/libsystem_blocks.dylib >> [ 19] F0635E0F-FE4B-34DB-ACF9-A58C1E9070E9 0x >> /usr/lib/system/libsystem_c.dylib >> [ 20] 56F94DCE-DBDE-3615-8F07-DE6270D9F8BE 0x >> /usr/lib/system/libsystem_configuration.dylib >> [ 21] 41B7C578-5A53-31C8-A96F-C73E030B0938 0x >> /usr/lib/system/libsystem_coreservices.dylib >> [ 22] 155DA0A9-2046-332E-BFA3-D7974A51F731 0x >> /usr/lib/system/libsystem_coretls.dylib >> [ 23] 0CEB5910-843F-315C-A1DE-5D955A48A045 0x >> /usr/lib/system/libsystem_dnssd.dylib >> [ 24] 2E16C4B3-A327-3957-9C41-143911979A1E 0x >> /usr/lib/system/libsystem_info.dylib >> [ 25] 16AD15EF-3DAE-3F63-9D26-26CCE1920762 0x >> /usr/lib/system/libsystem_kernel.dylib >> [ 26] 1E12AB45-6D96-36D0-A226-F24D9FB0D9D6 0x >> /usr/lib/system/libsystem_m.dylib >> [ 27] DDA8928B-CC0D-3255-BD8A-3FEA0982B890 0x >> /usr/lib/system/libsystem_malloc.dylib >> [ 28] 6105C134-6722-3C0A-A4CE-5E1261E2E1CC 0x >> /usr/lib/system/libsystem_network.dylib >> [ 29] BA58B30B-8377-3B0A-8AE3-4F84021D9D4E 0x >> /usr/lib/system/libsystem_networkextension.dylib >> [ 30] 61147800-F320-3DAA-850C-BADF33855F29 0x >> /usr/lib/system/libsystem_notify.dylib >> [ 31] 64E34079-D712-3D66-9CE2-418624A5C040 0x >> /usr/lib/system/libsystem_platform.dylib >> [ 32] ACE90967-ECD0-3251-AEEB-461E3C6414F7 0x >>
Re: [lldb-dev] LLDB: Unwinding based on Assembly Instruction Profiling
EH frame can't be used to unwind when we are in the first frame because it is only valid at call sites. It also can't be used in frames that are asynchronously interrupted like signal handler frames. So at frame zero, we typically just fall back to the default unwind plan for the current architecture which is usually follow the frame pointer for most systems. > On Oct 14, 2015, at 1:49 AM, Abhishek Aggarwal via lldb-dev > wrote: > > Hi > > As far as I know, if the unwinding based on Assembly Instruction > Profiling fails in LLDB then either EH frame unwinding or some other > mechanism comes into picture to unwind properly. Am I right? > > In this case, should LLDB change the unwinder plan from Assembly > Instruction Profiling to EH Frame based unwinding so that in future > the unwinding is always done with the new unwind plan rather than > first checking the assembly based unwind plan and then falling back to > EH Frame based unwind plan? > > > Thanks > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] incorrect shared library addresses
I am guessing that your binary is missing a LC_VERSION_MIN_XXX load command and so it is being loaded with "-unknown-unknown" as the architecture. This is probably causing LLDB to load the DynamicLoaderStatic as the dynamic loader which just loads all shared libraries as the address that is contained within the file itself, which is zero for most shared libraries. If you have a linker that is generating mach-o files, you will need to add a LC_VERSION_MIN_MACOSX load command to your executable so we know it is MacOSX. What does the output of "target list" show as the triple? It is probably "x86_64-unknown-unknown". We are often able to extract the correct triple for an executable from the executable itself. When no architecture if specified, it will default to the architecture that we detect in the main executable and this architecture will be used when a process asks for plug-ins to be created, line a DynamicLoader plug-in. If the triple is wrong, then we might select the wrong plug-ins for what you are trying to debug. You might be able to get around this for now by specifying this when you create your target: (lldb) target create --arch=x86_64-apple-macosx /tmp/gopath/bin/wikilinktester > On Oct 13, 2015, at 4:25 PM, Ryan Brown via lldb-dev > wrote: > > I'm having a strange issue debugging a go program. > > I set a breakpoint, and lldb stops at it. However, lldb thinks it's in a > different function: > (lldb) b wikilinktester.go:35 > Breakpoint 1: where = wikilinktester`main.main + 805 at wikilinktester.go:35, > address = 0x2365 > (lldb) r > Process 43141 launched: '/tmp/gopath/bin/wikilinktester' (x86_64) > Process 43141 stopped > * thread #5: tid = 0x0001, 0x2365 libOpenScriptingUtil.dylib, > stop reason = breakpoint 1.1 > frame #0: 0x2365 libOpenScriptingUtil.dylib > -> 0x2365: movq %rax, 0x48(%rsp) > 0x236a: movq %rax, (%rsp) > 0x236e: callq 0xb23d0 > 0x2373: movq 0x8(%rsp), %rbx > > For some reason lldb seems to think all the shared libraries are loaded at > address 0: > (lldb) image list > [ 0] 0x1000 > /tmp/gopath/bin/wikilinktester > [ 1] B1B370A5-479F-3533-8AD7-97B687D4F989 0x7fff5fc0 /usr/lib/dyld > [ 2] 1866C519-C5F3-3D09-8C17-A8F703664521 0x > /usr/lib/libSystem.B.dylib > [ 3] 5C0892B8-9691-341F-9279-CA3A74D59AA0 0x > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > [ 4] F4FD-043A-30CA-9997-4211CA0E9297 0x > /System/Library/Frameworks/Security.framework/Versions/A/Security > [ 5] 45E9A2E7-99C4-36B2-BEE3-0C4E11614AD1 0x > /usr/lib/system/libcache.dylib > [ 6] E789748D-F9A7-3CFF-B317-90DF348B1E95 0x > /usr/lib/system/libcommonCrypto.dylib > [ 7] BF8FC133-EE10-3DA6-9B90-92039E28678F 0x > /usr/lib/system/libcompiler_rt.dylib > [ 8] 0C68D3A6-ACDD-3EF3-991A-CC82C32AB836 0x > /usr/lib/system/libcopyfile.dylib > [ 9] 5779FFA0-4D9A-3AD4-B7F2-618227621DC8 0x > /usr/lib/system/libcorecrypto.dylib > [ 10] 502CF32B-669B-3709-8862-08188225E4F0 0x > /usr/lib/system/libdispatch.dylib > [ 11] CFBBE540-D503-3AFC-B5D6-644F1E69949B 0x > /usr/lib/system/libdyld.dylib > [ 12] 77845842-DE70-3CC5-BD01-C3D14227CED5 0x > /usr/lib/system/libkeymgr.dylib > [ 13] 4F81CA3A-D2CE-3030-A89D-42F3DAD7BA8F 0x > /usr/lib/system/liblaunch.dylib > [ 14] 126CA2ED-DE91-308F-8881-B9DAEC3C63B6 0x > /usr/lib/system/libmacho.dylib > [ 15] 7AF90041-2768-378A-925A-D83161863642 0x > /usr/lib/system/libquarantine.dylib > [ 16] 3485B5F4-6CE8-3C62-8DFD-8736ED6E8531 0x > /usr/lib/system/libremovefile.dylib > [ 17] F153AC5B-0542-356E-88C8-20A62CA704E2 0x > /usr/lib/system/libsystem_asl.dylib > [ 18] 9615D10A-FCA7-3BE4-AA1A-1B195DACE1A1 0x > /usr/lib/system/libsystem_blocks.dylib > [ 19] F0635E0F-FE4B-34DB-ACF9-A58C1E9070E9 0x > /usr/lib/system/libsystem_c.dylib > [ 20] 56F94DCE-DBDE-3615-8F07-DE6270D9F8BE 0x > /usr/lib/system/libsystem_configuration.dylib > [ 21] 41B7C578-5A53-31C8-A96F-C73E030B0938 0x > /usr/lib/system/libsystem_coreservices.dylib > [ 22] 155DA0A9-2046-332E-BFA3-D7974A51F731 0x > /usr/lib/system/libsystem_coretls.dylib > [ 23] 0CEB5910-843F-315C-A1DE-5D955A48A045 0x > /usr/lib/system/libsystem_dnssd.dylib > [ 24] 2E16C4B3-A327-3957-9C41-143911979A1E 0x > /usr/lib/system/libsystem_info.dylib > [ 25] 16AD15EF-3DAE-3F63-9D26-26CCE1920762 0x > /usr/lib/system/libsystem_kernel.dylib > [ 26] 1E12AB45-6D96-36D0-A226-F24D9FB0D9D6 0x > /usr/lib/system/libsystem_m.dylib > [ 27] DDA8928B-CC0D-3255-BD8A-3FEA0982B890 0x
Re: [lldb-dev] LLDB: Unwinding based on Assembly Instruction Profiling
On Wed, Oct 14, 2015 at 11:42:06AM -0700, Greg Clayton via lldb-dev wrote: > EH frame can't be used to unwind when we are in the first frame because > it is only valid at call sites. It also can't be used in frames that > are asynchronously interrupted like signal handler frames. This is not necessarily true, GCC can build them like that. I don't think we have a flag for clang/LLVM to create full async unwind tables. Joerg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Question on assert
Hi Tamas, There is an assert in DWARFDIE.cpp (lines 189 - 191) that we're hitting on the OS X side somewhat frequently nowadays: assert ((id&0xull) == 0 || (cu_id&0xll) == 0 || (id&0xull) == (cu_id&0x ll)); It does not seem to get hit consistently. We're trying to tease apart what it is trying to do. It's a bit strange since it is saying that the assert should not fire if any one of three clauses is true. But it's hard to figure out what exactly is going on there. Can you elucidate what this is trying to do? Thanks! -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB: Unwinding based on Assembly Instruction Profiling
> On Oct 14, 2015, at 1:02 PM, Joerg Sonnenberger via lldb-dev > wrote: > > On Wed, Oct 14, 2015 at 11:42:06AM -0700, Greg Clayton via lldb-dev wrote: >> EH frame can't be used to unwind when we are in the first frame because >> it is only valid at call sites. It also can't be used in frames that >> are asynchronously interrupted like signal handler frames. > > This is not necessarily true, GCC can build them like that. I don't > think we have a flag for clang/LLVM to create full async unwind tables. Most compilers don't generate stuff that is complete, and if it is complete, I am not aware of any markings on EH frame that states it is complete. So we really can't use it unless we know the info is complete. Was there ever an additional augmentation letter that was attached to the complete EH frame info? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] incorrect shared library addresses
Yep, it looks like LC_VERSION_MIN_MACOSX is missing. target list shows: target #0: /private/tmp/gopath/bin/wikilinktester ( arch=x86_64-apple-, platform=host ) specifying --arch doesn't seem to work. It still has the modules loaded starting at 0, and target list says: * target #1: /tmp/gopath/bin/wikilinktester ( arch=x86_64h-apple-macosx, platform=host, pid=48597, state=stopped ) If you link a go program with c code it uses the system linker, which does add LC_VERSION_MIN_MACOSX. That explains why I've never seen this before. Here's what that sort of binary looks like: (lldb) target list Current targets: * target #0: /private/tmp/gopath/bin/wikilinktester ( arch=x86_64-apple-macosx, platform=host, pid=49564, state=stopped ) (lldb) image list [ 0] DC92B610-E1DD-3CB2-AD7E-4EEF21E19D20 0x0400 /private/tmp/gopath/bin/wikilinktester [ 1] B1B370A5-479F-3533-8AD7-97B687D4F989 0x7fff5fc0 /usr/lib/dyld [ 2] 1866C519-C5F3-3D09-8C17-A8F703664521 0x7fff86ce6000 /usr/lib/libSystem.B.dylib [ 3] 5C0892B8-9691-341F-9279-CA3A74D59AA0 0x7fff8631a000 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation ... On Wed, Oct 14, 2015 at 11:49 AM Greg Clayton wrote: > I am guessing that your binary is missing a LC_VERSION_MIN_XXX load > command and so it is being loaded with "-unknown-unknown" as the > architecture. This is probably causing LLDB to load the DynamicLoaderStatic > as the dynamic loader which just loads all shared libraries as the address > that is contained within the file itself, which is zero for most shared > libraries. > > If you have a linker that is generating mach-o files, you will need to add > a LC_VERSION_MIN_MACOSX load command to your executable so we know it is > MacOSX. > > What does the output of "target list" show as the triple? It is probably > "x86_64-unknown-unknown". We are often able to extract the correct triple > for an executable from the executable itself. When no architecture if > specified, it will default to the architecture that we detect in the main > executable and this architecture will be used when a process asks for > plug-ins to be created, line a DynamicLoader plug-in. If the triple is > wrong, then we might select the wrong plug-ins for what you are trying to > debug. > > You might be able to get around this for now by specifying this when you > create your target: > > (lldb) target create --arch=x86_64-apple-macosx > /tmp/gopath/bin/wikilinktester > > > On Oct 13, 2015, at 4:25 PM, Ryan Brown via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > I'm having a strange issue debugging a go program. > > > > I set a breakpoint, and lldb stops at it. However, lldb thinks it's in a > different function: > > (lldb) b wikilinktester.go:35 > > Breakpoint 1: where = wikilinktester`main.main + 805 at > wikilinktester.go:35, address = 0x2365 > > (lldb) r > > Process 43141 launched: '/tmp/gopath/bin/wikilinktester' (x86_64) > > Process 43141 stopped > > * thread #5: tid = 0x0001, 0x2365 > libOpenScriptingUtil.dylib, stop reason = breakpoint 1.1 > > frame #0: 0x2365 libOpenScriptingUtil.dylib > > -> 0x2365: movq %rax, 0x48(%rsp) > > 0x236a: movq %rax, (%rsp) > > 0x236e: callq 0xb23d0 > > 0x2373: movq 0x8(%rsp), %rbx > > > > For some reason lldb seems to think all the shared libraries are loaded > at address 0: > > (lldb) image list > > [ 0] 0x1000 > /tmp/gopath/bin/wikilinktester > > [ 1] B1B370A5-479F-3533-8AD7-97B687D4F989 0x7fff5fc0 > /usr/lib/dyld > > [ 2] 1866C519-C5F3-3D09-8C17-A8F703664521 0x > /usr/lib/libSystem.B.dylib > > [ 3] 5C0892B8-9691-341F-9279-CA3A74D59AA0 0x > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > > [ 4] F4FD-043A-30CA-9997-4211CA0E9297 0x > /System/Library/Frameworks/Security.framework/Versions/A/Security > > [ 5] 45E9A2E7-99C4-36B2-BEE3-0C4E11614AD1 0x > /usr/lib/system/libcache.dylib > > [ 6] E789748D-F9A7-3CFF-B317-90DF348B1E95 0x > /usr/lib/system/libcommonCrypto.dylib > > [ 7] BF8FC133-EE10-3DA6-9B90-92039E28678F 0x > /usr/lib/system/libcompiler_rt.dylib > > [ 8] 0C68D3A6-ACDD-3EF3-991A-CC82C32AB836 0x > /usr/lib/system/libcopyfile.dylib > > [ 9] 5779FFA0-4D9A-3AD4-B7F2-618227621DC8 0x > /usr/lib/system/libcorecrypto.dylib > > [ 10] 502CF32B-669B-3709-8862-08188225E4F0 0x > /usr/lib/system/libdispatch.dylib > > [ 11] CFBBE540-D503-3AFC-B5D6-644F1E69949B 0x > /usr/lib/system/libdyld.dylib > > [ 12] 77845842-DE70-3CC5-BD01-C3D14227CED5 0x > /usr/lib/system/libkeymgr.dylib > > [ 13] 4F81CA3A-D2CE-3030-A89D-42F3DAD7BA8F 0x > /usr/lib/system/liblaunch.dylib > > [ 14] 126CA2ED-DE91-308F-8881-B9DAEC3C63B6 0x > /usr/lib/system/libmacho.dyl
Re: [lldb-dev] incorrect shared library addresses
Glad we identified your problem. Can you guys always use the system linker? Any reason to use another linker? If you continue to a custom linker you will want to modify it to set these. If you compile Go programs that run on iOS simulator or iOS you will want to emit a LC_MIN_VERSION_IOS. Greg Clayton > On Oct 14, 2015, at 1:49 PM, Ryan Brown wrote: > > Yep, it looks like LC_VERSION_MIN_MACOSX is missing. > target list shows: > target #0: /private/tmp/gopath/bin/wikilinktester ( arch=x86_64-apple-, > platform=host ) > specifying --arch doesn't seem to work. It still has the modules loaded > starting at 0, and target list says: > * target #1: /tmp/gopath/bin/wikilinktester ( arch=x86_64h-apple-macosx, > platform=host, pid=48597, state=stopped ) > > If you link a go program with c code it uses the system linker, which does > add LC_VERSION_MIN_MACOSX. That explains why I've never seen this before. > Here's what that sort of binary looks like: > (lldb) target list > Current targets: > * target #0: /private/tmp/gopath/bin/wikilinktester ( > arch=x86_64-apple-macosx, platform=host, pid=49564, state=stopped ) > (lldb) image list > [ 0] DC92B610-E1DD-3CB2-AD7E-4EEF21E19D20 0x0400 > /private/tmp/gopath/bin/wikilinktester > [ 1] B1B370A5-479F-3533-8AD7-97B687D4F989 0x7fff5fc0 /usr/lib/dyld > [ 2] 1866C519-C5F3-3D09-8C17-A8F703664521 0x7fff86ce6000 > /usr/lib/libSystem.B.dylib > [ 3] 5C0892B8-9691-341F-9279-CA3A74D59AA0 0x7fff8631a000 > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > ... > > > On Wed, Oct 14, 2015 at 11:49 AM Greg Clayton wrote: > I am guessing that your binary is missing a LC_VERSION_MIN_XXX load command > and so it is being loaded with "-unknown-unknown" as the architecture. > This is probably causing LLDB to load the DynamicLoaderStatic as the dynamic > loader which just loads all shared libraries as the address that is contained > within the file itself, which is zero for most shared libraries. > > If you have a linker that is generating mach-o files, you will need to add a > LC_VERSION_MIN_MACOSX load command to your executable so we know it is MacOSX. > > What does the output of "target list" show as the triple? It is probably > "x86_64-unknown-unknown". We are often able to extract the correct triple for > an executable from the executable itself. When no architecture if specified, > it will default to the architecture that we detect in the main executable and > this architecture will be used when a process asks for plug-ins to be > created, line a DynamicLoader plug-in. If the triple is wrong, then we might > select the wrong plug-ins for what you are trying to debug. > > You might be able to get around this for now by specifying this when you > create your target: > > (lldb) target create --arch=x86_64-apple-macosx /tmp/gopath/bin/wikilinktester > > > On Oct 13, 2015, at 4:25 PM, Ryan Brown via lldb-dev > > wrote: > > > > I'm having a strange issue debugging a go program. > > > > I set a breakpoint, and lldb stops at it. However, lldb thinks it's in a > > different function: > > (lldb) b wikilinktester.go:35 > > Breakpoint 1: where = wikilinktester`main.main + 805 at > > wikilinktester.go:35, address = 0x2365 > > (lldb) r > > Process 43141 launched: '/tmp/gopath/bin/wikilinktester' (x86_64) > > Process 43141 stopped > > * thread #5: tid = 0x0001, 0x2365 libOpenScriptingUtil.dylib, > > stop reason = breakpoint 1.1 > > frame #0: 0x2365 libOpenScriptingUtil.dylib > > -> 0x2365: movq %rax, 0x48(%rsp) > > 0x236a: movq %rax, (%rsp) > > 0x236e: callq 0xb23d0 > > 0x2373: movq 0x8(%rsp), %rbx > > > > For some reason lldb seems to think all the shared libraries are loaded at > > address 0: > > (lldb) image list > > [ 0] 0x1000 > > /tmp/gopath/bin/wikilinktester > > [ 1] B1B370A5-479F-3533-8AD7-97B687D4F989 0x7fff5fc0 /usr/lib/dyld > > [ 2] 1866C519-C5F3-3D09-8C17-A8F703664521 0x > > /usr/lib/libSystem.B.dylib > > [ 3] 5C0892B8-9691-341F-9279-CA3A74D59AA0 0x > > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > > [ 4] F4FD-043A-30CA-9997-4211CA0E9297 0x > > /System/Library/Frameworks/Security.framework/Versions/A/Security > > [ 5] 45E9A2E7-99C4-36B2-BEE3-0C4E11614AD1 0x > > /usr/lib/system/libcache.dylib > > [ 6] E789748D-F9A7-3CFF-B317-90DF348B1E95 0x > > /usr/lib/system/libcommonCrypto.dylib > > [ 7] BF8FC133-EE10-3DA6-9B90-92039E28678F 0x > > /usr/lib/system/libcompiler_rt.dylib > > [ 8] 0C68D3A6-ACDD-3EF3-991A-CC82C32AB836 0x > > /usr/lib/system/libcopyfile.dylib > > [ 9] 5779FFA0-4D9A-3AD4-B7F2-618227621DC8 0x > > /usr/lib/system/libcorecrypto.dylib > > [ 10] 502CF32B-669B-3709-8862-08188225E4F0 0x
[lldb-dev] error building fresh clone on os x
I just did a fresh svn clone, but I can't get it to build in xcode. It seems to be failing because it can't find something for ios. Is there some way to make it skip the ios stuff? ... llvm[3]: Copying runtime library darwin/profile_osx to build dir cp /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/tools/clang/runtime/compiler-rt/clang_darwin/asan_osx_dynamic/libcompiler_rt.dylib /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/Release+Asserts/lib/clang/3.8.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib cp /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/tools/clang/runtime/compiler-rt/clang_darwin/profile_osx/libcompiler_rt.a /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/Release+Asserts/lib/clang/3.8.0/lib/darwin/libclang_rt.profile_osx.a llvm[3]: Copying runtime library darwin/ubsan_osx_dynamic to build dir cp /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/tools/clang/runtime/compiler-rt/clang_darwin/ubsan_osx_dynamic/libcompiler_rt.dylib /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/Release+Asserts/lib/clang/3.8.0/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib llvm[3]: Copying runtime library darwin/ios to build dir cp /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/tools/clang/runtime/compiler-rt/clang_darwin/ios/libcompiler_rt.a /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/Release+Asserts/lib/clang/3.8.0/lib/darwin/libclang_rt.ios.a cp /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/tools/clang/runtime/compiler-rt/clang_darwin/osx/libcompiler_rt.a /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/Release+Asserts/lib/clang/3.8.0/lib/darwin/libclang_rt.osx.a cp /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/tools/clang/runtime/compiler-rt/clang_darwin/eprintf/libcompiler_rt.a /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/Release+Asserts/lib/clang/3.8.0/lib/darwin/libclang_rt.eprintf.a cp: /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/tools/clang/runtime/compiler-rt/clang_darwin/ios/libcompiler_rt.a: No such file or directory make[3]: *** [/Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/Release+Asserts/lib/clang/3.8.0/lib/darwin/libclang_rt.ios.a] Error 1 make[3]: *** Waiting for unfinished jobs rm /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/Release+Asserts/lib/clang/3.8.0/lib/macho_embedded/.dir /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/tools/clang/runtime/compiler-rt/clang_darwin/ubsan_osx_dynamic/libcompiler_rt.dylib /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/tools/clang/runtime/compiler-rt/clang_darwin/asan_osx_dynamic/libcompiler_rt.dylib /Users/ribrdb/Documents/git/lldb/llvm-build/Release+Asserts/x86_64/Release+Asserts/lib/clang/3.8.0/lib/darwin/.dir make[2]: *** [compiler-rt/.makeall] Error 2 make[1]: *** [all] Error 1 make: *** [all] Error 1 error: making llvm and clang child exited with value 2 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] incorrect shared library addresses
Well the go linker is actually what generates code from the IR, so it's always required. And as it stands now you can cross compile from another platform as long as you don't link with c code. I don't know if they'd want to change that by always using the os x linker. I filed a bug for them to add the min version. On a semi-related note, I've just discovered that the go compiler is writing line tables that increment the line number one instruction early. Would it make sense to try to work around this in LLDB? On Wed, Oct 14, 2015 at 3:15 PM Greg Clayton wrote: > Glad we identified your problem. Can you guys always use the system > linker? Any reason to use another linker? If you continue to a custom > linker you will want to modify it to set these. If you compile Go programs > that run on iOS simulator or iOS you will want to emit a LC_MIN_VERSION_IOS. > > Greg Clayton > > On Oct 14, 2015, at 1:49 PM, Ryan Brown wrote: > > > > Yep, it looks like LC_VERSION_MIN_MACOSX is missing. > > target list shows: > > target #0: /private/tmp/gopath/bin/wikilinktester ( > arch=x86_64-apple-, platform=host ) > > specifying --arch doesn't seem to work. It still has the modules loaded > starting at 0, and target list says: > > * target #1: /tmp/gopath/bin/wikilinktester ( arch=x86_64h-apple-macosx, > platform=host, pid=48597, state=stopped ) > > > > If you link a go program with c code it uses the system linker, which > does add LC_VERSION_MIN_MACOSX. That explains why I've never seen this > before. Here's what that sort of binary looks like: > > (lldb) target list > > Current targets: > > * target #0: /private/tmp/gopath/bin/wikilinktester ( > arch=x86_64-apple-macosx, platform=host, pid=49564, state=stopped ) > > (lldb) image list > > [ 0] DC92B610-E1DD-3CB2-AD7E-4EEF21E19D20 0x0400 > /private/tmp/gopath/bin/wikilinktester > > [ 1] B1B370A5-479F-3533-8AD7-97B687D4F989 0x7fff5fc0 > /usr/lib/dyld > > [ 2] 1866C519-C5F3-3D09-8C17-A8F703664521 0x7fff86ce6000 > /usr/lib/libSystem.B.dylib > > [ 3] 5C0892B8-9691-341F-9279-CA3A74D59AA0 0x7fff8631a000 > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > > ... > > > > > > On Wed, Oct 14, 2015 at 11:49 AM Greg Clayton > wrote: > > I am guessing that your binary is missing a LC_VERSION_MIN_XXX load > command and so it is being loaded with "-unknown-unknown" as the > architecture. This is probably causing LLDB to load the DynamicLoaderStatic > as the dynamic loader which just loads all shared libraries as the address > that is contained within the file itself, which is zero for most shared > libraries. > > > > If you have a linker that is generating mach-o files, you will need to > add a LC_VERSION_MIN_MACOSX load command to your executable so we know it > is MacOSX. > > > > What does the output of "target list" show as the triple? It is probably > "x86_64-unknown-unknown". We are often able to extract the correct triple > for an executable from the executable itself. When no architecture if > specified, it will default to the architecture that we detect in the main > executable and this architecture will be used when a process asks for > plug-ins to be created, line a DynamicLoader plug-in. If the triple is > wrong, then we might select the wrong plug-ins for what you are trying to > debug. > > > > You might be able to get around this for now by specifying this when you > create your target: > > > > (lldb) target create --arch=x86_64-apple-macosx > /tmp/gopath/bin/wikilinktester > > > > > On Oct 13, 2015, at 4:25 PM, Ryan Brown via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > I'm having a strange issue debugging a go program. > > > > > > I set a breakpoint, and lldb stops at it. However, lldb thinks it's in > a different function: > > > (lldb) b wikilinktester.go:35 > > > Breakpoint 1: where = wikilinktester`main.main + 805 at > wikilinktester.go:35, address = 0x2365 > > > (lldb) r > > > Process 43141 launched: '/tmp/gopath/bin/wikilinktester' (x86_64) > > > Process 43141 stopped > > > * thread #5: tid = 0x0001, 0x2365 > libOpenScriptingUtil.dylib, stop reason = breakpoint 1.1 > > > frame #0: 0x2365 libOpenScriptingUtil.dylib > > > -> 0x2365: movq %rax, 0x48(%rsp) > > > 0x236a: movq %rax, (%rsp) > > > 0x236e: callq 0xb23d0 > > > 0x2373: movq 0x8(%rsp), %rbx > > > > > > For some reason lldb seems to think all the shared libraries are > loaded at address 0: > > > (lldb) image list > > > [ 0] 0x1000 > /tmp/gopath/bin/wikilinktester > > > [ 1] B1B370A5-479F-3533-8AD7-97B687D4F989 0x7fff5fc0 > /usr/lib/dyld > > > [ 2] 1866C519-C5F3-3D09-8C17-A8F703664521 0x > /usr/lib/libSystem.B.dylib > > > [ 3] 5C0892B8-9691-341F-9279-CA3A74D59AA0 0x > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > > > [ 4] F4FD-043A-30CA-9997-4211CA0
Re: [lldb-dev] incorrect shared library addresses
> On Oct 14, 2015, at 4:04 PM, Ryan Brown wrote: > > Well the go linker is actually what generates code from the IR, so it's > always required. And as it stands now you can cross compile from another > platform as long as you don't link with c code. I don't know if they'd want > to change that by always using the os x linker. I filed a bug for them to add > the min version. Sounds good. > On a semi-related note, I've just discovered that the go compiler is writing > line tables that increment the line number one instruction early. Would it > make sense to try to work around this in LLDB? We should fix the compiler for this issue. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
