[lldb-dev] building on mac
Are there new prereqs for building on a mac? I just updated, and I'm getting this error: checking for __dso_handle... yes configure: WARNING: --enable-bindings=ocaml specified, but ctypes is not installed configure: WARNING: --enable-bindings=ocaml specified, but OUnit 2 is not installed. Tests will not run configure: error: Prequisites for bindings not satisfied. Fix them or use configure --disable-bindings. error: making llvm and clang child exited with value 2 -- Ryan Brown ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] building on mac
Does xcode use configure? I just push command-B. It does look like I have ocaml installed on my system, but I'm not sure how it go installed or why xcode is trying to use it. -- Ryan Brown On Thu, Dec 17, 2015 at 2:54 PM, Todd Fiala wrote: > We definitely should not be requiring ocaml :-) > > Are you using a configure-based build? If so, can you switch over to > using cmake and see if you see that same issue? We pretty much don't > maintain the configure build, and it is getting stripped from llvm and > clang in the next version of them after 3.8, so we will not be able to > support configure-based builds in the near future. > > In the event that you still see it, let us know if you have ocaml or opam > somewhere on your system. The warnings do seem to indicate that ocaml was > specified for one reason or another? Maybe parts of it were sniffed out > when trying to configure the build. > > -Todd > > On Thu, Dec 17, 2015 at 1:36 PM, Ryan Brown via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Are there new prereqs for building on a mac? >> I just updated, and I'm getting this error: >> >> checking for __dso_handle... yes >> >> configure: WARNING: --enable-bindings=ocaml specified, but ctypes is not >> installed >> >> configure: WARNING: --enable-bindings=ocaml specified, but OUnit 2 is not >> installed. Tests will not run >> >> configure: error: Prequisites for bindings not satisfied. Fix them or use >> configure --disable-bindings. >> >> error: making llvm and clang child exited with value 2 >> >> >> -- Ryan Brown >> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> > > > -- > -Todd > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] building on mac
Where do I find the script xcode is using? -- Ryan Brown On Fri, Dec 18, 2015 at 12:42 PM, Todd Fiala wrote: > Right: > > "Okay, this might be the llvm/clang build script that Xcode uses as an > llvm/clang build step. That's going to need to be updated if it is using > configure (for the reasons I mentioned above)." > > > > On Fri, Dec 18, 2015 at 10:26 AM, Zachary Turner > wrote: > >> Are the Xcode scripts using the llvm configure build? If so they will >> need to be changed to the CMake build sooner or later, because the >> configure build is going away in the near future. >> >> On Thu, Dec 17, 2015 at 3:18 PM Todd Fiala via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >>> Ah. >>> >>> Okay, this might be the llvm/clang build script that Xcode uses as an >>> llvm/clang build step. That's going to need to be updated if it is using >>> configure (for the reasons I mentioned above). >>> >>> So it sounds like some part of llvm or clang may be sniffing and finding >>> some part of ocaml, and deciding it should make some bindings for it. I'll >>> have a look at the script and see if there's an obvious way to explicitly >>> deny it (the warning seemed like it had a way to disable that binding, so >>> we might just need to work it in). >>> >>> Of course, if you are not using ocaml, you might want to consider >>> removing/hiding it if you don't need it. >>> >>> Interestingly, I did have ocaml on my home system a while back and >>> didn't have any trouble building, but I probably had ounit2 as well, and >>> likely wouldn't have noticed if the Xcode-based build-llvm script ended up >>> doing more work when building the embedded llvm/clang during the Xcode >>> build. >>> >>> I can probably replicate this pretty easily. >>> >>> On Thu, Dec 17, 2015 at 3:10 PM, Ryan Brown wrote: >>> >>>> Does xcode use configure? I just push command-B. >>>> It does look like I have ocaml installed on my system, but I'm not sure >>>> how it go installed or why xcode is trying to use it. >>>> >>>> -- Ryan Brown >>>> >>>> On Thu, Dec 17, 2015 at 2:54 PM, Todd Fiala >>>> wrote: >>>> >>>>> We definitely should not be requiring ocaml :-) >>>>> >>>>> Are you using a configure-based build? If so, can you switch over to >>>>> using cmake and see if you see that same issue? We pretty much don't >>>>> maintain the configure build, and it is getting stripped from llvm and >>>>> clang in the next version of them after 3.8, so we will not be able to >>>>> support configure-based builds in the near future. >>>>> >>>>> In the event that you still see it, let us know if you have ocaml or >>>>> opam somewhere on your system. The warnings do seem to indicate that >>>>> ocaml >>>>> was specified for one reason or another? Maybe parts of it were sniffed >>>>> out when trying to configure the build. >>>>> >>>>> -Todd >>>>> >>>>> On Thu, Dec 17, 2015 at 1:36 PM, Ryan Brown via lldb-dev < >>>>> lldb-dev@lists.llvm.org> wrote: >>>>> >>>>>> Are there new prereqs for building on a mac? >>>>>> I just updated, and I'm getting this error: >>>>>> >>>>>> checking for __dso_handle... yes >>>>>> >>>>>> configure: WARNING: --enable-bindings=ocaml specified, but ctypes is >>>>>> not installed >>>>>> >>>>>> configure: WARNING: --enable-bindings=ocaml specified, but OUnit 2 is >>>>>> not installed. Tests will not run >>>>>> >>>>>> configure: error: Prequisites for bindings not satisfied. Fix them or >>>>>> use configure --disable-bindings. >>>>>> >>>>>> error: making llvm and clang child exited with value 2 >>>>>> >>>>>> >>>>>> -- Ryan Brown >>>>>> >>>>>> ___ >>>>>> lldb-dev mailing list >>>>>> lldb-dev@lists.llvm.org >>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> -Todd >>>>> >>>> >>>> >>> >>> >>> -- >>> -Todd >>> ___ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> >> > > > -- > -Todd > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] type completion
I'm trying to implement a DWARFASTParser for go, and have hit an issue with
fields for structs.
As I understand it, DWARFASTParserClang loads minimal type info for structs
at first, and registers the type in SymbolFileDWARF's
m_forward_decl_clang_type_to_die.
Then later when you call type.GetFullCompilerType() it calls back into the
DWARFASTParser to complete the type.
But it seems like the SBValue's in the python API only get Forward types,
and never complete them. For example, I do:
var = frame.FindVariable('theStruct')
self.assertEqual(2, var.GetNumChildren())
But I get 0 children, because the type is incomplete and there doesn't seem
to be any way to complete it.
ValueObject::GetNumChildren goes through
ValueObject::MaybeCalculateCompleteType, which seems promising. But it only
completes the type for objc.
Would a clang variable already have a full type at this point for some
reason? If so, how do I arrange that for go?
Also, TypeSystem has a GetCompleteType method. I don't understand when this
would be called or how I can implement it without a reference to
SymbolFileDWARF.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Compiler types and renamings
On Thu, Sep 17, 2015 at 10:06 AM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > On Sep 17, 2015, at 3:08 AM, Bruce Mitchener > wrote: > > > > Howdy! > > > > I was looking at some of the CompilerType changes and had some questions > related to the recent cleanups and renamings. > > > > • clang_type_t is a typedef for void* and is used for the opaque > qual type code among other things. However, the m_type on CompilerType is > just a void*. Should we rename clang_type_t to compiler_type_t or just do > away with it and use void* instead? > > It might be a good idea to use something like "compiler_opaque_type_t" or > just "opaque_t", which is a typedef to "void *". Then we can use this to > CompilerDecl, CompilerDeclContext and CompilerType. > > > • SymbolFileDWARF has 2 typedefs, DIEToClangType and > ClangTypeToDIE which are used for 2 maps, m_forward_decl_die_to_clang_type > and m_forward_decl_clang_type_to_die. Should these be renamed to use > Compiler instead of Clang? > > They could be, but I really need to move these DIEToClangType and > ClangTypeToDIE over into DWARFASTParserClang. The problem it is isn't > saving the entire CompilerType it is just saving the clang_type_t and some > other type system, like Go's TypeSystem, could actually make a CompilerType > and use its type system and this "void *"... So this map is really just for > Clang types. The reason it wasn't moved was we only have one > DWARFASTParserClang when we have DWARF in .o files on MacOSX (we have a > "a.out" executable and it points to N SymbolFileDWARF instances (one for > each .o file where the .o files contain DWARF, but there is no DWARF in the > main executable) so I didn't want to move this map over into > DWARFASTParserClang since this would change things. So I vote to not rename > it for now and let users know this is for clang types only... > Actually the DWARFASTParserGo is using this too. Is that a problem? It seems like each die should only be associated with one compile unit and hence one type system. > > > • Any use of an instance of CompilerType in general code (code not > in a file with Clang in the name) can probably be renamed from clang_type > to compiler_type, right? This would include the clang_type member on Type. > > Yes! please do make the change to fix this. > > > I'd like to do any of the above, just want to make sure that it won't > clash with pending changes like this and that people actually want this to > happen. > > So please do the first and last and skip the DIEToClangType/ClangTypeToDIE > cleanup. > > Greg > > ___ > 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
[lldb-dev] incorrect shared library addresses
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 /usr/lib/system/libsystem_pthread.dylib [ 33] 3F5E973F-C702-31AC-97BC-05F5C195683C 0x /usr/lib/system/libsystem_sandbox.dylib [ 34] 581DAD0F-6B63-3A48-B63B-917AF799ABAA 0x /usr/lib/system/libsystem_secinit.dylib [ 35] D0E96837-3CF6-323D-B711-6DF6F660E530 0x /usr/lib/system/libsystem_stats.dylib [ 36] 840F5301-B55A-3078-90B9-FEFFD6CD741A 0x /usr/lib/system/libsystem_trace.dylib [ 37] 5676F7EA-C1DF-329F-B006-D2C3022B7D70 0x /usr/lib/system/libunc.dylib [ 38] BE7E51A0-B6EA-3A54-9CCA-9D88F683A6D6 0x /usr/lib/system/libunwind.dylib [ 39] 5C829202-962E-3744-8B50-00D38CC88E84 0x /usr/lib/system/libxpc.dylib [ 40] A260789B-D4D8-316A-9490-254767B8A5F1 0x /usr/lib/libauto.dylib [ 41] 2EE8E436-5CDC-34C5-9959-5BA218D507FB 0x /usr/lib/libDiagnosticMessagesClient.dylib [ 42] 3CD34752-B1F9-31D2-865D-B5B0F0BE3111 0x00
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/
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 &
[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 lld
Re: [lldb-dev] Python object lifetimes affect the reliability of tests
Couldn't we just change DeleteTarget to make sure everything is unmapped?
On Thu, Oct 15, 2015 at 11:34 AM Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> To add more evidence for this, here's a small repro:
>
> import sys
>
> print "sys.exc_info() = ", "Empty" if sys.exc_info() == (None, None, None)
> else "Valid"
> try:
> raise Exception
> except Exception, e:
> print "sys.exc_info() = ", "Empty" if sys.exc_info() == (None, None,
> None) else "Valid"
> pass
>
> print "sys.exc_info() = ", "Empty" if sys.exc_info() == (None, None, None)
> else "Valid"
> print "e = ", "Bound" if 'e' in vars() else "Unbound"
> pass
>
> For me this prints
> sys.exc_info() = Empty
> sys.exc_info() = Valid
> sys.exc_info() = Valid
> e = Bound
>
> On Thu, Oct 15, 2015 at 11:21 AM Zachary Turner
> wrote:
>
>> We actually do already to the self.dbg.DeleteTarget(target), and that's
>> the line that's failing. The reason it's failing is because the 'sc'
>> reference is still alive, which is holding an mmap, which causes a
>> mandatory file lock on Windows.
>>
>> The diagnostics went pretty deep into python internals, but I think we
>> might have figured it out. I don't know if this is a bug in Python, but I
>> think we'd probably need to ask Guido to be sure :)
>>
>> As far as we can tell, what happens is that on the exceptional codepath
>> (e.g the assert fails), you walk back up the stack until you get to the
>> except handler. This exception handler is in TestCase.run(). After it
>> handles the exception it goes and runs teardown. However, for some reason,
>> Python is still holding a strong reference to the *traceback*, even though
>> we're completely out of the finally block. What this means is that if you
>> call `sys.exc_info()` *even after you've exited the finally block, it still
>> returns info about the previous exception that's not even being handled
>> anymore. I would have expected this to be gone since there's no exception
>> in-fligth anymore. So basically, Python is still holding a reference to
>> the active exception, the exception holds the stack frame, the stack frame
>> holds the test method, the test method has locals, one of which is a
>> SymbolList, a member of which is symbol context, which has the file locked.
>>
>> Our best guess is that if you have something like this:
>>
>> def foo():
>> try:
>># Do stuff
>> except Exception, e:
>>pass
>> # Do more stuff
>>
>> that if the exceptional path is executed, then both e and sys.exc_info()
>> are alive *while* do more stuff is happening. We've found two ways to
>> fixthis:
>>
>> 1) Change to this:
>> def foo():
>> try:
>># Do stuff
>> except Exception, e:
>>pass
>> del e
>> sys.exc_clear()
>> # Do more stuff
>>
>> 2) Put the try / except inside a function. When the function returns,
>> sys.exc_info() is cleared.
>>
>> I like 2 better, but we're still testing some more to make sure this
>> really fixes it 100% of the time.
>>
>> On Thu, Oct 15, 2015 at 10:25 AM Greg Clayton via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>>
>>> > On Oct 15, 2015, at 8:50 AM, Adrian McCarthy via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>> >
>>> > I've tracked down a source of flakiness in tests on Windows to Python
>>> object lifetimes and the SB interface, and I'm wondering how best to handle
>>> it.
>>> >
>>> > Consider this portion of a test from TestTargetAPI:
>>> >
>>> > def find_functions(self, exe_name):
>>> > """Exercise SBTaget.FindFunctions() API."""
>>> > exe = os.path.join(os.getcwd(), exe_name)
>>> >
>>> > # Create a target by the debugger.
>>> > target = self.dbg.CreateTarget(exe)
>>> > self.assertTrue(target, VALID_TARGET)
>>> > list = target.FindFunctions('c', lldb.eFunctionNameTypeAuto)
>>> > self.assertTrue(list.GetSize() == 1)
>>> >
>>> > for sc in list:
>>> > self.assertTrue(sc.GetModule().GetFileSpec().GetFilename() ==
>>> exe_name)
>>> > self.assertTrue(sc.GetSymbol().GetName() == 'c')
>>> >
>>> > The local variables go out of scope when the function exits, but the
>>> SB (C++) objects they represent aren't (always) immediately destroyed. At
>>> least some of these objects keep references to the executable module in the
>>> shared module list, so when the test framework cleans up and calls
>>> `SBDebugger::DeleteTarget`, the module isn't orphaned, so LLDB maintains an
>>> open handle to the executable.
>>>
>>> Creating a target with:
>>>
>>> target = self.dbg.CreateTarget(exe)
>>>
>>> Will give you a SBTarget object that has a strong reference to the
>>> target, but the debugger still has a copy in its target list, so the
>>> SBTarget isn't designed to delete the object when the target variable goes
>>> out of scope. If you want the target to be deleted, you actually have to
>>> call through to the debugger with:
>>>
>>>
>>> bool
>>> SBDebugger:DeleteTarget (lldb::SBTarg
