Re: [Lldb-commits] [PATCH] D21296: [lldb] Fixed race condition on private state thread exit, take 2
labath accepted this revision. labath added a comment. Seems to run fine on linux now. Thanks for investigating this. We'll monitor the buildbots and let you know if anything bad happens. ;) BTW. your comment in ControlPrivateStateThread seems to indicate that the linux behavior is inconsistent/unexpected in some way. Do you think it would be worth filing a bug about that? http://reviews.llvm.org/D21296 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21221: Fix for PrintStackTraces
ravitheja added inline comments. Comment at: source/Plugins/Process/Utility/RegisterContextLLDB.cpp:1602 @@ -1610,3 +1601,3 @@ // isn't going to do any better. -if (m_full_unwind_plan_sp->GetSourcedFromCompiler() == eLazyBoolYes) -return false; +//if (m_full_unwind_plan_sp->GetSourcedFromCompiler() == eLazyBoolYes) +//return false; labath wrote: > What is this supposed to do? It stops the the TryFallbackUnwindplan to use the assembly unwinder. http://reviews.llvm.org/D21221 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21221: Fix for PrintStackTraces
ravitheja added a comment. so regarding this particular situation I want to give little more insight -> It starts out from here 0x40143a <+346>: movabsq $0x403e32, %rdi ; imm = 0x403E32 0x401444 <+356>: movb $0x0, %al 0x401446 <+358>: callq 0x400d30 ; symbol stub for: printf 0x40144b <+363>: movq 0x6071c0, %rdi 0x401453 <+371>: movl %eax, -0xdc(%rbp) ->0x401459 <+377>: callq 0x400ed0 ; symbol stub for: fflush 0x40145e <+382>: movl $0x40, %esi 0x401463 <+387>: leaq -0xb0(%rbp), %rdi 0x40146a <+394>: movq 0x607158, %rdx 0x401472 <+402>: movl %eax, -0xe0(%rbp) (lldb) disassemble a.out`fflush: -> 0x400ed0 <+0>: jmpq *0x206212(%rip) ; _GLOBAL_OFFSET_TABLE_ + 232 0x400ed6 <+6>: pushq $0x1a 0x400edb <+11>: jmp0x400d20 (lldb) disassemble -> 0x400d20: pushq 0x2062e2(%rip); _GLOBAL_OFFSET_TABLE_ + 8 0x400d26: jmpq *0x2062e4(%rip) ; _GLOBAL_OFFSET_TABLE_ + 16 I think this jump goes to fflush. ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2: 0x77df04a0 <+0>: subq $0x38, %rsp-> The testcase tries to unwind out of here and fails. 0x77df04a4 <+4>: movq %rax, (%rsp) 0x77df04a8 <+8>: movq %rcx, 0x8(%rsp) 0x77df04ad <+13>: movq %rdx, 0x10(%rsp) 0x77df04b2 <+18>: movq %rsi, 0x18(%rsp) 0x77df04b7 <+23>: movq %rdi, 0x20(%rsp) 0x77df04bc <+28>: movq %r8, 0x28(%rsp) 0x77df04c1 <+33>: movq %r9, 0x30(%rsp) 0x77df04c6 <+38>: movq 0x40(%rsp), %rsi Now as you can see, from inside fflush its not possible for the assembly unwind to figure out the situation. @jasonmolenda The functions I posted in the lldb-dev are the same, here i am just posting how it got there. There is eh_frame information for these functions, that is able to correctly point out the CFA. lldb) image show-unwind --address 0x77df04a0 UNWIND PLANS for ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2 (start addr 0x77df04a0) Asynchronous (not restricted to call-sites) UnwindPlan is 'assembly insn profiling' Synchronous (restricted to call-sites) UnwindPlan is 'eh_frame CFI' Assembly language inspection UnwindPlan: This UnwindPlan originally sourced from assembly insn profiling This UnwindPlan is sourced from the compiler: no. This UnwindPlan is valid at all instruction locations: yes. Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text + 88512-0x00015a30) row[0]:0: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8] row[1]:4: CFA=rsp+64 => rsp=CFA+0 rip=[CFA-8] row[2]: 94: CFA=rsp -8 => rsp=CFA+0 rip=[CFA-8] eh_frame UnwindPlan: This UnwindPlan originally sourced from eh_frame CFI This UnwindPlan is sourced from the compiler: yes. This UnwindPlan is valid at all instruction locations: no. Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text + 88512-0x00015a21) row[0]:0: CFA=rsp+24 => rip=[CFA-8] row[1]:4: CFA=rsp+80 => rip=[CFA-8] row[2]: 94: CFA=rsp +8 => rip=[CFA-8] Arch default UnwindPlan: This UnwindPlan originally sourced from x86_64 default unwind plan This UnwindPlan is sourced from the compiler: no. This UnwindPlan is valid at all instruction locations: no. row[0]:0: CFA=rbp+16 => rbp=[CFA-16] rsp=CFA+0 rip=[CFA-8] Arch default at entry point UnwindPlan: This UnwindPlan originally sourced from x86_64 at-func-entry default This UnwindPlan is sourced from the compiler: no. This UnwindPlan is valid at all instruction locations: not specified. row[0]:0: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8] As you can see the eh_frame UnwindPlan is correct here. http://reviews.llvm.org/D21221 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21221: Fix for PrintStackTraces
ravitheja added a comment. @labath In order to reproduce this situation without the help of standard library, I would have to write handwritten assembly and the CFI directives for that, is that fine ? http://reviews.llvm.org/D21221 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21221: Fix for PrintStackTraces
labath added a comment. In http://reviews.llvm.org/D21221#457329, @ravitheja wrote: > @labath In order to reproduce this situation without the help of standard > library, I would have to write handwritten assembly and the CFI directives > for that, is that fine ? Yes, I think that's fine. Obviously that will make the test x86-specific (and probably linux-specific, although it would be great if that can be avoided (*)), but at least it will be well focused, and not relying on random timings in other tests. A less preferred but-still-better-than-status-quo option would be to keep the standard library dependency but remove the timing issues (e.g., by setting the breakpoint in fflush, instruction-stepping 100 times, and making sure you unwind correctly from each place). (*) One way to do that is to avoid running code. If you can write the test in a way that it does not need a running process then you can just check in a tiny (linux) module, load it and query some properties of the contained functions and their unwind plans... http://reviews.llvm.org/D21221 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D20565: Add MemoryRegionInfo to SB API
hhellyer added a comment. Should I be able to deliver these changes now? When I try following the instructions here: http://llvm.org/docs/Phabricator.html the patch downloads and applies correctly but whether I use arc via the git or svn commit methods I'm ultimately prompted for a password for subversion. I'm not sure if I should have a password or if that means the patch doesn't match what's expected in some way. I don't know how clever phabricator's svn commit hooks are and whether they check against the patch before prompting for authentication. (Or is there a "Land this" button on phabricator I'm missing?) From: Greg Clayton To: Howard Hellyer/UK/IBM@IBMGB, clayb...@gmail.com Date: 13/06/2016 21:28 Subject:Re: [PATCH] http://reviews.llvm.org/D20565: Add MemoryRegionInfo to SB API clayborg accepted this revision. This revision is now accepted and ready to land. http://reviews.llvm.org/D20565 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU http://reviews.llvm.org/D20565 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D21324: Remove Platform usages from NativeProcessLinux
labath created this revision.
labath added a reviewer: tberghammer.
labath added subscribers: lldb-commits, omjavaid, nitesh.jain, uweigand.
This removes the last usage of the Platform plugin in NPL. It was being
used for determining the architecture of the debugged process. I replace
the call that went through the Platform plugin with a lower level call
on the ObjectFile directly.
http://reviews.llvm.org/D21324
Files:
source/Plugins/Process/Linux/NativeProcessLinux.cpp
source/Plugins/Process/Linux/NativeProcessLinux.h
Index: source/Plugins/Process/Linux/NativeProcessLinux.h
===
--- source/Plugins/Process/Linux/NativeProcessLinux.h
+++ source/Plugins/Process/Linux/NativeProcessLinux.h
@@ -26,7 +26,6 @@
namespace lldb_private {
class Error;
-class Module;
class Scalar;
namespace process_linux {
@@ -156,18 +155,12 @@
/// launching a child process.
struct LaunchArgs
{
-LaunchArgs(Module *module,
-char const **argv,
-char const **envp,
-const FileSpec &stdin_file_spec,
-const FileSpec &stdout_file_spec,
-const FileSpec &stderr_file_spec,
-const FileSpec &working_dir,
-const ProcessLaunchInfo &launch_info);
+LaunchArgs(char const **argv, char const **envp, const FileSpec &stdin_file_spec,
+ const FileSpec &stdout_file_spec, const FileSpec &stderr_file_spec, const FileSpec &working_dir,
+ const ProcessLaunchInfo &launch_info);
~LaunchArgs();
-Module *m_module; // The executable image to launch.
char const **m_argv; // Process arguments.
char const **m_envp; // Process environment.
const FileSpec m_stdin_file_spec; // Redirect stdin if not empty.
@@ -189,7 +182,6 @@
void
LaunchInferior (
MainLoop &mainloop,
-Module *module,
char const *argv[],
char const *envp[],
const FileSpec &stdin_file_spec,
Index: source/Plugins/Process/Linux/NativeProcessLinux.cpp
===
--- source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -25,15 +25,14 @@
// Other libraries and framework includes
#include "lldb/Core/EmulateInstruction.h"
#include "lldb/Core/Error.h"
-#include "lldb/Core/Module.h"
#include "lldb/Core/ModuleSpec.h"
#include "lldb/Core/RegisterValue.h"
#include "lldb/Core/State.h"
-#include "lldb/Host/common/NativeBreakpoint.h"
-#include "lldb/Host/common/NativeRegisterContext.h"
#include "lldb/Host/Host.h"
#include "lldb/Host/ThreadLauncher.h"
-#include "lldb/Target/Platform.h"
+#include "lldb/Host/common/NativeBreakpoint.h"
+#include "lldb/Host/common/NativeRegisterContext.h"
+#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/ProcessLaunchInfo.h"
#include "lldb/Target/Target.h"
@@ -110,33 +109,26 @@
namespace
{
-Error
-ResolveProcessArchitecture (lldb::pid_t pid, Platform &platform, ArchSpec &arch)
-{
-// Grab process info for the running process.
-ProcessInstanceInfo process_info;
-if (!platform.GetProcessInfo (pid, process_info))
-return Error("failed to get process info");
-
-// Resolve the executable module.
-ModuleSP exe_module_sp;
-ModuleSpec exe_module_spec(process_info.GetExecutableFile(), process_info.GetArchitecture());
-FileSpecList executable_search_paths (Target::GetDefaultExecutableSearchPaths ());
-Error error = platform.ResolveExecutable(
-exe_module_spec,
-exe_module_sp,
-executable_search_paths.GetSize () ? &executable_search_paths : NULL);
+Error
+ResolveProcessArchitecture(lldb::pid_t pid, ArchSpec &arch)
+{
+// Grab process info for the running process.
+ProcessInstanceInfo process_info;
+if (!Host::GetProcessInfo(pid, process_info))
+return Error("failed to get process info");
-if (!error.Success ())
-return error;
+// Resolve the executable module.
+ModuleSpecList module_specs;
+if (!ObjectFile::GetModuleSpecifications(process_info.GetExecutableFile(), 0, 0, module_specs))
+return Error("failed to get module specifications");
+assert(module_specs.GetSize() == 1);
-// Check if we've got our architecture from the exe_module.
-arch = exe_module_sp->GetArchitecture ();
-if (arch.IsValid ())
-return Error();
-else
-return Error("failed to retrieve a valid architecture from the exe module");
-}
+arch = module_specs.GetModuleSpecRefAtIndex(0).GetArchitecture();
+if
Re: [Lldb-commits] [PATCH] D20368: Remove Platform usages from NativeProcessLinux
labath abandoned this revision.
labath added a comment.
I am abandoning this in favor of http://reviews.llvm.org/D21324, which achieves
the same result (no Platform plugin), but still uses the elf-parsing method to
keep everything working as is now.
You can give it a try if you want, but I don't anticipate any
architecture-specific problems as all the changes are in generic code. Thanks
for the patience.
Comment at: source/Plugins/Process/Linux/NativeProcessLinux.cpp:2072-2073
@@ -2164,4 +2071,4 @@
lldb::addr_t
NativeProcessLinux::GetSharedLibraryInfoAddress ()
{
The function is pure virtual in the base class, so I cannot just remove it.
http://reviews.llvm.org/D20368
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21324: Remove Platform usages from NativeProcessLinux
tberghammer accepted this revision. tberghammer added a comment. This revision is now accepted and ready to land. Looks good http://reviews.llvm.org/D21324 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21296: [lldb] Fixed race condition on private state thread exit, take 2
cameron314 added a comment. Thanks everyone :-) Ah, yeah, sorry if I gave the wrong impression, but that comment is not specific to Linux (in fact, I've only seen it once, on Windows). At one point the debugger had entered ControlPrivateStateThread on one thread to stop it, seen that the thread was already in an invalid state (it was), and assumed that meant that the thread was already exiting and did a join without sending the stop. But the state thread somehow wasn't on its way out yet, it was stuck waiting for a control event first (this is the part that I'm not sure should be possible, but empirically is). This caused a deadlock. So I changed my patch to always send the event if the thread is joinable, not just if its state is valid, and left that comment to explain why this must remain so. http://reviews.llvm.org/D21296 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r272682 - [lldb] Fixed race conditions on private state thread exit
Author: cameron314
Date: Tue Jun 14 11:22:45 2016
New Revision: 272682
URL: http://llvm.org/viewvc/llvm-project?rev=272682&view=rev
Log:
[lldb] Fixed race conditions on private state thread exit
This patch fixes various races between the time the private state thread is
signaled to exit and the time it actually exits (during which it no longer
responds to events). Previously, this was consistently causing 2-second timeout
delays on process detach/stop for us.
This also prevents crashes that were caused by the thread controlling its own
owning pointer while the controller was using it (copying the thread wrapper is
not enough to mitigate this, since the internal thread object was getting reset
anyway). Again, we were seeing this consistently.
Differential Revision: http://reviews.llvm.org/D21296
Modified:
lldb/trunk/include/lldb/Target/Process.h
lldb/trunk/source/Target/Process.cpp
Modified: lldb/trunk/include/lldb/Target/Process.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Process.h?rev=272682&r1=272681&r2=272682&view=diff
==
--- lldb/trunk/include/lldb/Target/Process.h (original)
+++ lldb/trunk/include/lldb/Target/Process.h Tue Jun 14 11:22:45 2016
@@ -3309,9 +3309,13 @@ protected:
bool
PrivateStateThreadIsValid () const
{
-return m_private_state_thread.IsJoinable();
+lldb::StateType state = m_private_state.GetValue();
+return state != lldb::eStateInvalid &&
+ state != lldb::eStateDetached &&
+ state != lldb::eStateExited &&
+ m_private_state_thread.IsJoinable();
}
-
+
void
ForceNextEventDelivery()
{
Modified: lldb/trunk/source/Target/Process.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Process.cpp?rev=272682&r1=272681&r2=272682&view=diff
==
--- lldb/trunk/source/Target/Process.cpp (original)
+++ lldb/trunk/source/Target/Process.cpp Tue Jun 14 11:22:45 2016
@@ -4088,7 +4088,7 @@ Process::ResumePrivateStateThread ()
void
Process::StopPrivateStateThread ()
{
-if (PrivateStateThreadIsValid ())
+if (m_private_state_thread.IsJoinable ())
ControlPrivateStateThread (eBroadcastInternalStateControlStop);
else
{
@@ -4110,21 +4110,23 @@ Process::ControlPrivateStateThread (uint
if (log)
log->Printf ("Process::%s (signal = %d)", __FUNCTION__, signal);
-// Signal the private state thread. First we should copy this is case the
-// thread starts exiting since the private state thread will NULL this out
-// when it exits
+// Signal the private state thread
+if (m_private_state_thread.IsJoinable())
{
-HostThread private_state_thread(m_private_state_thread);
-if (private_state_thread.IsJoinable())
+// Broadcast the event.
+// It is important to do this outside of the if below, because
+// it's possible that the thread state is invalid but that the
+// thread is waiting on a control event instead of simply being
+// on its way out (this should not happen, but it apparently can).
+if (log)
+log->Printf ("Sending control event of type: %d.", signal);
+std::shared_ptr event_receipt_sp(new
EventDataReceipt());
+m_private_state_control_broadcaster.BroadcastEvent(signal,
event_receipt_sp);
+
+// Wait for the event receipt or for the private state thread to exit
+bool receipt_received = false;
+if (PrivateStateThreadIsValid())
{
-if (log)
-log->Printf ("Sending control event of type: %d.", signal);
-// Send the control event and wait for the receipt or for the
private state
-// thread to exit
-std::shared_ptr event_receipt_sp(new
EventDataReceipt());
-m_private_state_control_broadcaster.BroadcastEvent(signal,
event_receipt_sp);
-
-bool receipt_received = false;
while (!receipt_received)
{
bool timed_out = false;
@@ -4137,23 +4139,24 @@ Process::ControlPrivateStateThread (uint
if (!receipt_received)
{
// Check if the private state thread is still around. If
it isn't then we are done waiting
-if (!m_private_state_thread.IsJoinable())
-break; // Private state thread exited, we are done
+if (!PrivateStateThreadIsValid())
+break; // Private state thread exited or is exiting,
we are done
}
}
-
-if (signal == eBroadcastInternalStateControlStop)
-{
-thread_result_t result = NULL;
-private_state_thread.Join(&result);
-}
}
-else
+
+
Re: [Lldb-commits] [PATCH] D21296: [lldb] Fixed race condition on private state thread exit, take 2
This revision was automatically updated to reflect the committed changes.
Closed by commit rL272682: [lldb] Fixed race conditions on private state thread
exit (authored by cameron314).
Changed prior to commit:
http://reviews.llvm.org/D21296?vs=60536&id=60693#toc
Repository:
rL LLVM
http://reviews.llvm.org/D21296
Files:
lldb/trunk/include/lldb/Target/Process.h
lldb/trunk/source/Target/Process.cpp
Index: lldb/trunk/source/Target/Process.cpp
===
--- lldb/trunk/source/Target/Process.cpp
+++ lldb/trunk/source/Target/Process.cpp
@@ -4088,7 +4088,7 @@
void
Process::StopPrivateStateThread ()
{
-if (PrivateStateThreadIsValid ())
+if (m_private_state_thread.IsJoinable ())
ControlPrivateStateThread (eBroadcastInternalStateControlStop);
else
{
@@ -4110,21 +4110,23 @@
if (log)
log->Printf ("Process::%s (signal = %d)", __FUNCTION__, signal);
-// Signal the private state thread. First we should copy this is case the
-// thread starts exiting since the private state thread will NULL this out
-// when it exits
+// Signal the private state thread
+if (m_private_state_thread.IsJoinable())
{
-HostThread private_state_thread(m_private_state_thread);
-if (private_state_thread.IsJoinable())
+// Broadcast the event.
+// It is important to do this outside of the if below, because
+// it's possible that the thread state is invalid but that the
+// thread is waiting on a control event instead of simply being
+// on its way out (this should not happen, but it apparently can).
+if (log)
+log->Printf ("Sending control event of type: %d.", signal);
+std::shared_ptr event_receipt_sp(new EventDataReceipt());
+m_private_state_control_broadcaster.BroadcastEvent(signal, event_receipt_sp);
+
+// Wait for the event receipt or for the private state thread to exit
+bool receipt_received = false;
+if (PrivateStateThreadIsValid())
{
-if (log)
-log->Printf ("Sending control event of type: %d.", signal);
-// Send the control event and wait for the receipt or for the private state
-// thread to exit
-std::shared_ptr event_receipt_sp(new EventDataReceipt());
-m_private_state_control_broadcaster.BroadcastEvent(signal, event_receipt_sp);
-
-bool receipt_received = false;
while (!receipt_received)
{
bool timed_out = false;
@@ -4137,23 +4139,24 @@
if (!receipt_received)
{
// Check if the private state thread is still around. If it isn't then we are done waiting
-if (!m_private_state_thread.IsJoinable())
-break; // Private state thread exited, we are done
+if (!PrivateStateThreadIsValid())
+break; // Private state thread exited or is exiting, we are done
}
}
-
-if (signal == eBroadcastInternalStateControlStop)
-{
-thread_result_t result = NULL;
-private_state_thread.Join(&result);
-}
}
-else
+
+if (signal == eBroadcastInternalStateControlStop)
{
-if (log)
-log->Printf ("Private state thread already dead, no need to signal it to stop.");
+thread_result_t result = NULL;
+m_private_state_thread.Join(&result);
+m_private_state_thread.Reset();
}
}
+else
+{
+if (log)
+log->Printf("Private state thread already dead, no need to signal it to stop.");
+}
}
void
@@ -4446,7 +4449,6 @@
// try to change it on the way out.
if (!is_secondary_thread)
m_public_run_lock.SetStopped();
-m_private_state_thread.Reset();
return NULL;
}
Index: lldb/trunk/include/lldb/Target/Process.h
===
--- lldb/trunk/include/lldb/Target/Process.h
+++ lldb/trunk/include/lldb/Target/Process.h
@@ -3309,9 +3309,13 @@
bool
PrivateStateThreadIsValid () const
{
-return m_private_state_thread.IsJoinable();
+lldb::StateType state = m_private_state.GetValue();
+return state != lldb::eStateInvalid &&
+ state != lldb::eStateDetached &&
+ state != lldb::eStateExited &&
+ m_private_state_thread.IsJoinable();
}
-
+
void
ForceNextEventDelivery()
{
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D21328: [lldb] Fixed incorrect endianness when evaluating certain expressions
cameron314 created this revision.
cameron314 added reviewers: spyffe, zturner, clayborg.
cameron314 added a subscriber: lldb-commits.
The `EntityVariable` materializer was, under certain conditions, taking the
bytes of a `DataExtractor` that were potentially in host order (e.g. little
endian) and putting them in the `IRMemoryMap` (which assumes all values are in
target order, e.g. big endian). This caused certain values to have the wrong
endianness during expression evaluation.
On our platform, this manifested as certain expressions yielding incorrect
results when the variables were in registers (e.g. `argc + 1` would give
`0x0101`).
http://reviews.llvm.org/D21328
Files:
include/lldb/Expression/IRMemoryMap.h
source/Expression/IRMemoryMap.cpp
source/Expression/Materializer.cpp
Index: source/Expression/Materializer.cpp
===
--- source/Expression/Materializer.cpp
+++ source/Expression/Materializer.cpp
@@ -575,7 +575,7 @@
Error write_error;
-map.WriteMemory(m_temporary_allocation, data.GetDataStart(),
data.GetByteSize(), write_error);
+map.WriteMemory(m_temporary_allocation, data.GetDataStart(),
data.GetByteSize(), data.GetByteOrder(), write_error);
if (!write_error.Success())
{
Index: source/Expression/IRMemoryMap.cpp
===
--- source/Expression/IRMemoryMap.cpp
+++ source/Expression/IRMemoryMap.cpp
@@ -564,6 +564,22 @@
}
void
+IRMemoryMap::WriteMemory(lldb::addr_t process_address, const uint8_t *bytes,
size_t size, lldb::ByteOrder byteOrder, Error &error)
+{
+std::vector temp;
+if (byteOrder != GetByteOrder())
+{
+// Need to byte-swap the bytes before putting them in the map,
otherwise they'll
+// be interpreted with the wrong endianness when they're read back out.
+temp.reserve(size);
+typedef std::reverse_iterator revit;
+temp.assign(revit(bytes + size), revit(bytes));
+bytes = temp.data();
+}
+WriteMemory(process_address, bytes, size, error);
+}
+
+void
IRMemoryMap::WriteMemory (lldb::addr_t process_address, const uint8_t *bytes,
size_t size, Error &error)
{
error.Clear();
Index: include/lldb/Expression/IRMemoryMap.h
===
--- include/lldb/Expression/IRMemoryMap.h
+++ include/lldb/Expression/IRMemoryMap.h
@@ -60,6 +60,7 @@
void Free (lldb::addr_t process_address, Error &error);
void WriteMemory (lldb::addr_t process_address, const uint8_t *bytes,
size_t size, Error &error);
+void WriteMemory (lldb::addr_t process_address, const uint8_t *bytes,
size_t size, lldb::ByteOrder order, Error &error);
void WriteScalarToMemory (lldb::addr_t process_address, Scalar &scalar,
size_t size, Error &error);
void WritePointerToMemory (lldb::addr_t process_address, lldb::addr_t
address, Error &error);
void ReadMemory (uint8_t *bytes, lldb::addr_t process_address, size_t
size, Error &error);
Index: source/Expression/Materializer.cpp
===
--- source/Expression/Materializer.cpp
+++ source/Expression/Materializer.cpp
@@ -575,7 +575,7 @@
Error write_error;
-map.WriteMemory(m_temporary_allocation, data.GetDataStart(), data.GetByteSize(), write_error);
+map.WriteMemory(m_temporary_allocation, data.GetDataStart(), data.GetByteSize(), data.GetByteOrder(), write_error);
if (!write_error.Success())
{
Index: source/Expression/IRMemoryMap.cpp
===
--- source/Expression/IRMemoryMap.cpp
+++ source/Expression/IRMemoryMap.cpp
@@ -564,6 +564,22 @@
}
void
+IRMemoryMap::WriteMemory(lldb::addr_t process_address, const uint8_t *bytes, size_t size, lldb::ByteOrder byteOrder, Error &error)
+{
+std::vector temp;
+if (byteOrder != GetByteOrder())
+{
+// Need to byte-swap the bytes before putting them in the map, otherwise they'll
+// be interpreted with the wrong endianness when they're read back out.
+temp.reserve(size);
+typedef std::reverse_iterator revit;
+temp.assign(revit(bytes + size), revit(bytes));
+bytes = temp.data();
+}
+WriteMemory(process_address, bytes, size, error);
+}
+
+void
IRMemoryMap::WriteMemory (lldb::addr_t process_address, const uint8_t *bytes, size_t size, Error &error)
{
error.Clear();
Index: include/lldb/Expression/IRMemoryMap.h
===
--- include/lldb/Expression/IRMemoryMap.h
+++ include/lldb/Expression/IRMemoryMap.h
@@ -60,6 +60,7 @@
void Free (lldb::addr_t process_address, Error &error);
void WriteMemory (lldb::addr_t process_address, const
[Lldb-commits] [lldb] r272686 - Remove Platform usages from NativeProcessLinux
Author: labath
Date: Tue Jun 14 12:30:52 2016
New Revision: 272686
URL: http://llvm.org/viewvc/llvm-project?rev=272686&view=rev
Log:
Remove Platform usages from NativeProcessLinux
Summary:
This removes the last usage of the Platform plugin in NPL. It was being
used for determining the architecture of the debugged process. I replace
the call that went through the Platform plugin with a lower level call
on the ObjectFile directly.
Reviewers: tberghammer
Subscribers: uweigand, nitesh.jain, omjavaid, lldb-commits
Differential Revision: http://reviews.llvm.org/D21324
Modified:
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h
Modified: lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp?rev=272686&r1=272685&r2=272686&view=diff
==
--- lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp (original)
+++ lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp Tue Jun 14
12:30:52 2016
@@ -25,15 +25,14 @@
// Other libraries and framework includes
#include "lldb/Core/EmulateInstruction.h"
#include "lldb/Core/Error.h"
-#include "lldb/Core/Module.h"
#include "lldb/Core/ModuleSpec.h"
#include "lldb/Core/RegisterValue.h"
#include "lldb/Core/State.h"
-#include "lldb/Host/common/NativeBreakpoint.h"
-#include "lldb/Host/common/NativeRegisterContext.h"
#include "lldb/Host/Host.h"
#include "lldb/Host/ThreadLauncher.h"
-#include "lldb/Target/Platform.h"
+#include "lldb/Host/common/NativeBreakpoint.h"
+#include "lldb/Host/common/NativeRegisterContext.h"
+#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/ProcessLaunchInfo.h"
#include "lldb/Target/Target.h"
@@ -110,33 +109,26 @@ static bool ProcessVmReadvSupported()
namespace
{
-Error
-ResolveProcessArchitecture (lldb::pid_t pid, Platform &platform, ArchSpec
&arch)
-{
-// Grab process info for the running process.
-ProcessInstanceInfo process_info;
-if (!platform.GetProcessInfo (pid, process_info))
-return Error("failed to get process info");
-
-// Resolve the executable module.
-ModuleSP exe_module_sp;
-ModuleSpec exe_module_spec(process_info.GetExecutableFile(),
process_info.GetArchitecture());
-FileSpecList executable_search_paths
(Target::GetDefaultExecutableSearchPaths ());
-Error error = platform.ResolveExecutable(
-exe_module_spec,
-exe_module_sp,
-executable_search_paths.GetSize () ? &executable_search_paths :
NULL);
-
-if (!error.Success ())
-return error;
+Error
+ResolveProcessArchitecture(lldb::pid_t pid, ArchSpec &arch)
+{
+// Grab process info for the running process.
+ProcessInstanceInfo process_info;
+if (!Host::GetProcessInfo(pid, process_info))
+return Error("failed to get process info");
-// Check if we've got our architecture from the exe_module.
-arch = exe_module_sp->GetArchitecture ();
-if (arch.IsValid ())
-return Error();
-else
-return Error("failed to retrieve a valid architecture from the exe
module");
-}
+// Resolve the executable module.
+ModuleSpecList module_specs;
+if (!ObjectFile::GetModuleSpecifications(process_info.GetExecutableFile(),
0, 0, module_specs))
+return Error("failed to get module specifications");
+assert(module_specs.GetSize() == 1);
+
+arch = module_specs.GetModuleSpecRefAtIndex(0).GetArchitecture();
+if (arch.IsValid())
+return Error();
+else
+return Error("failed to retrieve a valid architecture from the exe
module");
+}
void
DisplayBytes (StreamString &s, void *bytes, uint32_t count)
@@ -238,16 +230,10 @@ EnsureFDFlags(int fd, int flags)
return error;
}
-NativeProcessLinux::LaunchArgs::LaunchArgs(Module *module,
- char const **argv,
- char const **envp,
- const FileSpec &stdin_file_spec,
- const FileSpec &stdout_file_spec,
- const FileSpec &stderr_file_spec,
- const FileSpec &working_dir,
- const ProcessLaunchInfo &launch_info)
-: m_module(module),
- m_argv(argv),
+NativeProcessLinux::LaunchArgs::LaunchArgs(char const **argv, char const
**envp, const FileSpec &stdin_file_spec,
+ const FileSpec &stdout_file_spec,
const FileSpec &stderr_file_spec,
+ const FileSpec &working_dir, const
ProcessLaunchInfo &launch_info)
+: m_argv(a
Re: [Lldb-commits] [PATCH] D21324: Remove Platform usages from NativeProcessLinux
This revision was automatically updated to reflect the committed changes.
Closed by commit rL272686: Remove Platform usages from NativeProcessLinux
(authored by labath).
Changed prior to commit:
http://reviews.llvm.org/D21324?vs=60679&id=60705#toc
Repository:
rL LLVM
http://reviews.llvm.org/D21324
Files:
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h
Index: lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h
===
--- lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h
+++ lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h
@@ -26,7 +26,6 @@
namespace lldb_private {
class Error;
-class Module;
class Scalar;
namespace process_linux {
@@ -156,18 +155,12 @@
/// launching a child process.
struct LaunchArgs
{
-LaunchArgs(Module *module,
-char const **argv,
-char const **envp,
-const FileSpec &stdin_file_spec,
-const FileSpec &stdout_file_spec,
-const FileSpec &stderr_file_spec,
-const FileSpec &working_dir,
-const ProcessLaunchInfo &launch_info);
+LaunchArgs(char const **argv, char const **envp, const FileSpec &stdin_file_spec,
+ const FileSpec &stdout_file_spec, const FileSpec &stderr_file_spec, const FileSpec &working_dir,
+ const ProcessLaunchInfo &launch_info);
~LaunchArgs();
-Module *m_module; // The executable image to launch.
char const **m_argv; // Process arguments.
char const **m_envp; // Process environment.
const FileSpec m_stdin_file_spec; // Redirect stdin if not empty.
@@ -189,7 +182,6 @@
void
LaunchInferior (
MainLoop &mainloop,
-Module *module,
char const *argv[],
char const *envp[],
const FileSpec &stdin_file_spec,
Index: lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
===
--- lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -25,15 +25,14 @@
// Other libraries and framework includes
#include "lldb/Core/EmulateInstruction.h"
#include "lldb/Core/Error.h"
-#include "lldb/Core/Module.h"
#include "lldb/Core/ModuleSpec.h"
#include "lldb/Core/RegisterValue.h"
#include "lldb/Core/State.h"
-#include "lldb/Host/common/NativeBreakpoint.h"
-#include "lldb/Host/common/NativeRegisterContext.h"
#include "lldb/Host/Host.h"
#include "lldb/Host/ThreadLauncher.h"
-#include "lldb/Target/Platform.h"
+#include "lldb/Host/common/NativeBreakpoint.h"
+#include "lldb/Host/common/NativeRegisterContext.h"
+#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/ProcessLaunchInfo.h"
#include "lldb/Target/Target.h"
@@ -110,33 +109,26 @@
namespace
{
-Error
-ResolveProcessArchitecture (lldb::pid_t pid, Platform &platform, ArchSpec &arch)
-{
-// Grab process info for the running process.
-ProcessInstanceInfo process_info;
-if (!platform.GetProcessInfo (pid, process_info))
-return Error("failed to get process info");
-
-// Resolve the executable module.
-ModuleSP exe_module_sp;
-ModuleSpec exe_module_spec(process_info.GetExecutableFile(), process_info.GetArchitecture());
-FileSpecList executable_search_paths (Target::GetDefaultExecutableSearchPaths ());
-Error error = platform.ResolveExecutable(
-exe_module_spec,
-exe_module_sp,
-executable_search_paths.GetSize () ? &executable_search_paths : NULL);
+Error
+ResolveProcessArchitecture(lldb::pid_t pid, ArchSpec &arch)
+{
+// Grab process info for the running process.
+ProcessInstanceInfo process_info;
+if (!Host::GetProcessInfo(pid, process_info))
+return Error("failed to get process info");
-if (!error.Success ())
-return error;
+// Resolve the executable module.
+ModuleSpecList module_specs;
+if (!ObjectFile::GetModuleSpecifications(process_info.GetExecutableFile(), 0, 0, module_specs))
+return Error("failed to get module specifications");
+assert(module_specs.GetSize() == 1);
-// Check if we've got our architecture from the exe_module.
-arch = exe_module_sp->GetArchitecture ();
-if (arch.IsValid ())
-return Error();
-else
-return Error("failed to retrieve a valid architecture from the exe module");
-}
+arch = module_specs.GetModuleSpecRefAtIndex(0).GetArchitecture();
+if (arch.IsValid())
+
Re: [Lldb-commits] [PATCH] D21296: [lldb] Fixed race condition on private state thread exit, take 2
OK, i see. Thanks for the explanation. This may actually be some windows specific thing then, as I remember zachary mentioning they have some flakyness issues there. BTW, this has sped up the LLDB test suite nearly 2x, so thanks a lot for that. :) pl On 14 June 2016 at 17:13, Cameron wrote: > cameron314 added a comment. > > Thanks everyone :-) > > Ah, yeah, sorry if I gave the wrong impression, but that comment is not > specific to Linux (in fact, I've only seen it once, on Windows). At one point > the debugger had entered ControlPrivateStateThread on one thread to stop it, > seen that the thread was already in an invalid state (it was), and assumed > that meant that the thread was already exiting and did a join without sending > the stop. But the state thread somehow wasn't on its way out yet, it was > stuck waiting for a control event first (this is the part that I'm not sure > should be possible, but empirically is). This caused a deadlock. So I changed > my patch to always send the event if the thread is joinable, not just if its > state is valid, and left that comment to explain why this must remain so. > > > http://reviews.llvm.org/D21296 > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21296: [lldb] Fixed race condition on private state thread exit, take 2
labath added a subscriber: labath. labath added a comment. OK, i see. Thanks for the explanation. This may actually be some windows specific thing then, as I remember zachary mentioning they have some flakyness issues there. BTW, this has sped up the LLDB test suite nearly 2x, so thanks a lot for that. :) pl Repository: rL LLVM http://reviews.llvm.org/D21296 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] LLVM buildmaster will be restarted tonight
Hello everyone, LLVM buildmaster will be restarted after 8 PM Pacific time today. Thanks Galina ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] Buildbot numbers for the last week of 6/05/2016 - 6/11/2016
Hello everyone, Below are some buildbot numbers for the last week of 6/05/2016 - 6/11/2016. Thanks Galina buildername | was_red ---+--- sanitizer-x86_64-linux-bootstrap | 134:12:25 perf-x86_64-penryn-O3-polly-parallel-fast | 46:29:26 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 37:56:11 polly-amd64-linux | 34:53:03 sanitizer-x86_64-linux-fuzzer | 30:17:25 clang-x64-ninja-win7 | 25:37:00 llvm-clang-lld-x86_64-debian-fast | 25:32:54 clang-cmake-thumbv7-a15-full-sh | 25:31:44 clang-x86-win2008-selfhost| 25:25:42 clang-atom-d525-fedora-rel| 24:52:25 sanitizer-x86_64-linux| 24:21:15 clang-ppc64be-linux-lnt | 24:19:40 clang-ppc64be-linux | 24:02:53 sanitizer-ppc64le-linux | 22:44:45 lldb-windows7-android | 20:42:45 sanitizer-ppc64be-linux | 19:49:26 llvm-sphinx-docs | 19:44:43 clang-s390x-linux | 17:18:07 clang-cmake-mips | 16:39:48 perf-x86_64-penryn-O3 | 16:32:12 clang-cuda-build | 12:52:45 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 11:58:08 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 11:23:05 clang-ppc64le-linux | 10:55:20 perf-x86_64-penryn-O3-polly | 10:09:52 libcxx-libcxxabi-x86_64-linux-debian | 06:31:45 clang-cmake-armv7-a15-selfhost| 04:54:20 clang-ppc64le-linux-multistage| 04:39:08 clang-cmake-mipsel| 04:07:57 lldb-x86_64-darwin-13.4 | 04:07:15 clang-native-arm-lnt | 04:02:19 lld-x86_64-win7 | 04:01:13 clang-cmake-aarch64-full | 03:44:15 clang-cmake-armv7-a15-full| 03:39:18 clang-cmake-armv7-a15 | 03:28:48 clang-cmake-thumbv7-a15 | 03:28:06 libcxx-libcxxabi-arm-linux| 03:19:42 clang-ppc64le-linux-lnt | 03:17:11 clang-x86_64-linux-selfhost-modules | 02:58:31 clang-cmake-aarch64-quick | 02:39:58 libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi | 02:25:49 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11 | 02:25:33 libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 02:22:56 llvm-mips-linux | 02:22:54 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 02:22:39 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03| 02:19:56 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 02:19:30 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z| 02:17:10 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 02:14:04 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 02:13:58 libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu| 02:13:27 lldb-x86_64-ubuntu-14.04-android | 02:10:25 lldb-x86_64-ubuntu-14.04-buildserver | 02:02:39 clang-x86_64-debian-fast | 01:52:47 sanitizer-x86_64-linux-fast | 01:41:33 lldb-amd64-ninja-netbsd7 | 01:36:27 perf-x86_64-penryn-O3-polly-unprofitable | 01:33:54 clang-x86_64-linux-abi-test | 01:26:12 sanitizer-x86_64-linux-autoconf | 01:21:50 llvm-hexagon-elf | 00:57:39 clang-hexagon-elf | 00:54:37 lldb-amd64-ninja-freebsd11| 00:43:02 lldb-x86_64-ubuntu-14.04-cmake| 00:35:59 lld-x86_64-freebsd| 00:26:47 perf-x86_64-penryn-O3-polly-fast | 00:25:38 sanitizer-windows | 00:24:51 lld-x86_64-darwin13 | 00:16:59 (67 rows) "Status change ratio" by active builder (p
Re: [Lldb-commits] [PATCH] D21221: Fix for PrintStackTraces
jasonmolenda added a comment.
Thanks Ravi, I see the problem here and I agree that lldb should use eh_frame
to unwind from this function - that's the only way this is going to work. I'm
surprised that there is accurate eh_frame instructions for this function, it's
great to see it.
I'm wondering if we can come up with a way to detect this scenario - where
we're unwinding from a function that doesn't conform to the ABI. I know it's a
little special-case-y but what if we modified
FuncUnwinders::GetUnwindPlanAtNonCallSite to:
Get the assembly unwind plan, eh_frame unwind plan, the ABI
ArchitectureDefaultAtFunctionEntry unwind plan, and the ArchitectureDefault
unwind plan.
If the eh_frame's row 0 (initial set of unwind instructions) has a pc/lr
restore rule that doesn't match any of the other three unwind plans, then we
assume that the eh_frame instructions have knowledge that the others do not
have, and we use eh_frame for this function.
I'll write this up tomorrow and see if it works on mac (although we've almost
completely stopped using eh_frame on our platform so I'm not a very good test
bed at all) - I can imagine how the code would look and I think it's possible
to do.
If eh_frame accurately describes the prologue instructions (I think I mentioned
in the lldb-dev emails a couple weeks ago -- it is not required to describe the
prologue), it the pc unwind rule will be the same as the ABI's
ArchitectureDefaultAtFunctionEntry. Or it will be the same as the assembly
unwind rule. If the eh_frame doesn't describe the prologue -- if the 0th row
is the register state after the prologue has executed -- it will match the ABI
ArchitectureDefault's unwind rule to restore the pc.
The main oddity here are architectures like arm where the restore rule for pc
may be in terms of the pc, or it may be in terms of the link register ("return
address register" in lldb's terminology). Different UnwindPlans may specify
how to restore the pc register value, or how to restore the ra register value
-- they're inconsistent -- and that needs to be taken into account.
I know this isn't the approach you took with the patch, but I think it would be
an improvement to lldb (especially if systems are getting eh_frame like this)
and it will solve the problem I believe. What do you think? As I said, I'm
happy to write up what I'm suggesting here, I don't want to ask you to do extra
work to try out this idea. I'm in and out of the office this week because of
an apple conference but I'll try to get something together over the next few
days.
As for writing test cases, these are tricky, and I need to write unwind test
cases too, it's something I haven't had time to do yet for lldb and we really
need these test cases, the unwinder is VERY hard to work on without a rich
testsuite.
They end up being architecture (x86_64) and platform (mac) specific... you
write a top-level driver in C which calls hand-written assembly functions
(either inlined or a .s file) and the little details / ABI vary from platform
to platform, I'm not sure if it's worth trying to make them portable - we can
rely on buildbots to run them on the matrix of systems if nothing else. The
only alternative are core files of processes in the correct stopped state - but
then you have to store gigantic core files and possibly binaries along with
them and I don't think we're going to head down that route any time soon.
http://reviews.llvm.org/D21221
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] Buildbot numbers for the last week of 6/05/2016 - 6/11/2016
Some of these tables are getting quite mangled somewhere along the line (email client? mailing list handling? idk). Could you re-send with the tables also attached or something else that avoids that problem? -- Sean Silva On Tue, Jun 14, 2016 at 4:23 PM, Galina Kistanova via cfe-commits < cfe-comm...@lists.llvm.org> wrote: > Hello everyone, > > Below are some buildbot numbers for the last week of 6/05/2016 - 6/11/2016. > > Thanks > > Galina > > > > buildername | was_red > ---+--- > sanitizer-x86_64-linux-bootstrap | 134:12:25 > perf-x86_64-penryn-O3-polly-parallel-fast | 46:29:26 > llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 37:56:11 > polly-amd64-linux | 34:53:03 > sanitizer-x86_64-linux-fuzzer | 30:17:25 > clang-x64-ninja-win7 | 25:37:00 > llvm-clang-lld-x86_64-debian-fast | 25:32:54 > clang-cmake-thumbv7-a15-full-sh | 25:31:44 > clang-x86-win2008-selfhost| 25:25:42 > clang-atom-d525-fedora-rel| 24:52:25 > sanitizer-x86_64-linux| 24:21:15 > clang-ppc64be-linux-lnt | 24:19:40 > clang-ppc64be-linux | 24:02:53 > sanitizer-ppc64le-linux | 22:44:45 > lldb-windows7-android | 20:42:45 > sanitizer-ppc64be-linux | 19:49:26 > llvm-sphinx-docs | 19:44:43 > clang-s390x-linux | 17:18:07 > clang-cmake-mips | 16:39:48 > perf-x86_64-penryn-O3 | 16:32:12 > clang-cuda-build | 12:52:45 > llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 11:58:08 > perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 11:23:05 > clang-ppc64le-linux | 10:55:20 > perf-x86_64-penryn-O3-polly | 10:09:52 > libcxx-libcxxabi-x86_64-linux-debian | 06:31:45 > clang-cmake-armv7-a15-selfhost| 04:54:20 > clang-ppc64le-linux-multistage| 04:39:08 > clang-cmake-mipsel| 04:07:57 > lldb-x86_64-darwin-13.4 | 04:07:15 > clang-native-arm-lnt | 04:02:19 > lld-x86_64-win7 | 04:01:13 > clang-cmake-aarch64-full | 03:44:15 > clang-cmake-armv7-a15-full| 03:39:18 > clang-cmake-armv7-a15 | 03:28:48 > clang-cmake-thumbv7-a15 | 03:28:06 > libcxx-libcxxabi-arm-linux| 03:19:42 > clang-ppc64le-linux-lnt | 03:17:11 > clang-x86_64-linux-selfhost-modules | 02:58:31 > clang-cmake-aarch64-quick | 02:39:58 > libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi | 02:25:49 > libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11 | 02:25:33 > libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 02:22:56 > llvm-mips-linux | 02:22:54 > libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 02:22:39 > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03| 02:19:56 > libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 02:19:30 > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z| 02:17:10 > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 02:14:04 > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 02:13:58 > libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu| 02:13:27 > lldb-x86_64-ubuntu-14.04-android | 02:10:25 > lldb-x86_64-ubuntu-14.04-buildserver | 02:02:39 > clang-x86_64-debian-fast | 01:52:47 > sanitizer-x86_64-linux-fast | 01:41:33 > lldb-amd64-ninja-netbsd7 | 01:36:27 > perf-x86_64-penryn-O3-polly-unprofitable | 01:33:54 > clang-x86_64-linux-abi-test | 01:26:12 > sanitizer-x86_64-linux-autoconf | 01:21:50 > llvm-hexagon-elf | 00:57:39 > clang-hexagon-elf | 00:54:37 > ll
[Lldb-commits] [lldb] r272751 - Add results.xml for macOS lldb unittests
Author: penryu
Date: Tue Jun 14 22:53:21 2016
New Revision: 272751
URL: http://llvm.org/viewvc/llvm-project?rev=272751&view=rev
Log:
Add results.xml for macOS lldb unittests
http://reviews.llvm.org/D21211
If gtest tests of lldb fail, there are no test results for Jenkins to
consume. This will make the results of the gtest failure available to
Jenkins.
This is to address the failure visible in:
http://lab.llvm.org:8080/green/job/lldb_build_test/19196/
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=272751&r1=272750&r2=272751&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Tue Jun 14 22:53:21 2016
@@ -6336,7 +6336,7 @@
);
runOnlyForDeploymentPostprocessing = 0;
shellPath = /bin/sh;
- shellScript = "# Run the just-built gtest
executable\n\n# Uncomment this to see the steps in action\n# set -x\n\n# We
need to hide the lldb.py that goes into BUILT_PRODUCTS\n# because it will
conflict with finding the lldb module later,\n# which causes the python
exception tests to fail.\nif [ -f \"${BUILT_PRODUCTS_DIR}/lldb.py\" ]; then\n
mv -f \"${BUILT_PRODUCTS_DIR}/lldb.py\"
\"${BUILT_PRODUCTS_DIR}/park.lldb.py\"\nfi\n\n# Tell lldb-gtest where to find
the lldb package\nexport
PYTHONPATH=${BUILT_PRODUCTS_DIR}/LLDB.framework/Resources/Python\n\n# We must
redirect stdin to /dev/null: without this, xcodebuild\n# will wait forever for
input when we run the TestExceptionStateChecking\n#
test.\n${BUILT_PRODUCTS_DIR}/lldb-gtest < /dev/null\nRETCODE=$?\n\nif [ -f
\"${BUILT_PRODUCTS_DIR}/park.lldb.py\" ]; then\nmv -f
\"${BUILT_PRODUCTS_DIR}/park.lldb.py\"
\"${BUILT_PRODUCTS_DIR}/lldb.py\"\nfi\n\nexit ${RETCODE}";
+ shellScript = "# Run the just-built gtest
executable\n\n# Uncomment this to see the steps in action\n# set -x\n\n# We
need to hide the lldb.py that goes into BUILT_PRODUCTS\n# because it will
conflict with finding the lldb module later,\n# which causes the python
exception tests to fail.\nif [ -f \"${BUILT_PRODUCTS_DIR}/lldb.py\" ]; then\n
mv -f \"${BUILT_PRODUCTS_DIR}/lldb.py\"
\"${BUILT_PRODUCTS_DIR}/park.lldb.py\"\nfi\n\n# Tell lldb-gtest where to find
the lldb package\nexport
PYTHONPATH=${BUILT_PRODUCTS_DIR}/LLDB.framework/Resources/Python\n\n# We must
redirect stdin to /dev/null: without this, xcodebuild\n# will wait forever for
input when we run the TestExceptionStateChecking\n#
test.\n${BUILT_PRODUCTS_DIR}/lldb-gtest
--gtest_output=xml:${BUILD_DIR}/gtest-results.xml < /dev/null\nRETCODE=$?\n\nif
[ -f \"${BUILT_PRODUCTS_DIR}/park.lldb.py\" ]; then\nmv -f
\"${BUILT_PRODUCTS_DIR}/park.lldb.py\"
\"${BUILT_PRODUCTS_DIR}/lldb.py\"\nfi\n\nexit ${RETCODE}";
};
261B5A7511C3FA6F00AABD0A /* Fixup Framework Headers */ = {
isa = PBXShellScriptBuildPhase;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
