> On Feb 23, 2015, at 1:04 PM, Paul Smith <p...@mad-scientist.net> wrote: > > On Mon, 2015-02-23 at 10:58 -0800, Greg Clayton wrote: >> The race condition is definitely there for source command files. Since >> it may or may not bork the heap, I would suggest possibly adding a >> "script import time; time.usleep(250000)" before the image list unless >> you get the top of tree sources. > > Ah. Clever. I'll give that a go. > > I did build the latest code and as predicted it failed during codesign: > > /bin/sh -c > /Users/build/pds/lldb/build/lldb.build/Release/lldb-server.build/Script-4C3326CA18B2A2B800EB5DD7.sh > lldb_codesign: no identity found > > I haven't had time to dig into this further yet.
Follow the instructions in: svn cat http://llvm.org/svn/llvm-project/lldb/trunk/docs/code-signing.txt > >>> Is there another/better way to get the fully-qualified name of the >>> executable that was running, given nothing but the coredump? >> >> No, the dynamic loader will be able to figure it out and then you >> might need to lookup your binary on a build server using the UUID, >> path and triple. > > Sure; in my case I'm examining the core immediately after it happens (we > check for cores after we run each test) so I always have the binary > right there... but tests can run multiple binaries and it's not always > obvious which one the core belongs to. Getting the fully-qualified path > out of the core file is all I need for this particular situation. Gotcha, you will still need to load it in LLDB and let the dynamic loader figure it out. _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
