Re: [Lldb-commits] [PATCH] D16049: [LLDB][MIPS] A small fix in GetBreakableLoadAddress() for MIPS
bhushan updated this revision to Diff 45364.
bhushan added a comment.
As suggested by Greg, added new function `matchArchitectures(archs)` which
handles "archs".
This function can be used by other decorator functions for testing "archs".
Repository:
rL LLVM
http://reviews.llvm.org/D16049
Files:
include/lldb/API/SBInstruction.h
packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/Makefile
packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/TestAvoidBreakpointInDelaySlot.py
packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/main.c
packages/Python/lldbsuite/test/lldbtest.py
scripts/interface/SBInstruction.i
source/API/SBInstruction.cpp
source/Target/Target.cpp
Index: packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/main.c
===
--- /dev/null
+++ packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/main.c
@@ -0,0 +1,21 @@
+#include
+
+foo (int a, int b)
+{
+int c;
+if (a<=b)
+c=b-a;
+else
+c=b+a;
+return c;
+}
+
+int main()
+{
+int a=7, b=8, c;
+
+c = foo(a, b);
+
+return 0;
+}
+
Index: packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/TestAvoidBreakpointInDelaySlot.py
===
--- /dev/null
+++ packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/TestAvoidBreakpointInDelaySlot.py
@@ -0,0 +1,82 @@
+"""
+Test specific to MIPS
+"""
+
+import os, time
+import re
+import unittest2
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+class AvoidBreakpointInDelaySlotAPITestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@skipUnlessArch(archs=re.compile('mips*'))
+def test(self):
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+self.expect("file " + exe,
+patterns = [ "Current executable set to .*a.out.*" ])
+
+# Create a target by the debugger.
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+
+breakpoint = target.BreakpointCreateByName('main', 'a.out')
+self.assertTrue(breakpoint and
+breakpoint.GetNumLocations() == 1,
+VALID_BREAKPOINT)
+
+# Now launch the process, and do not stop at entry point.
+process = target.LaunchSimple (None, None, self.get_process_working_directory())
+self.assertTrue(process, PROCESS_IS_VALID)
+
+list = target.FindFunctions('foo', lldb.eFunctionNameTypeAuto)
+self.assertTrue(list.GetSize() == 1)
+sc = list.GetContextAtIndex(0)
+self.assertTrue(sc.GetSymbol().GetName() == "foo")
+function = sc.GetFunction()
+self.assertTrue(function)
+self.function(function, target)
+
+def function (self, function, target):
+"""Iterate over instructions in function and place a breakpoint on delay slot instruction"""
+# Get the list of all instructions in the function
+insts = function.GetInstructions(target)
+print insts
+i = 0
+for inst in insts:
+if (inst.HasDelaySlot()):
+# Remember the address of branch instruction.
+branchinstaddress = inst.GetAddress().GetLoadAddress(target)
+
+# Get next instruction i.e delay slot instruction.
+delayinst = insts.GetInstructionAtIndex(i+1)
+delayinstaddr = delayinst.GetAddress().GetLoadAddress(target)
+
+# Set breakpoint on delay slot instruction
+breakpoint = target.BreakpointCreateByAddress(delayinstaddr)
+
+# Verify the breakpoint.
+self.assertTrue(breakpoint and
+breakpoint.GetNumLocations() == 1,
+VALID_BREAKPOINT)
+# Get the location from breakpoint
+location = breakpoint.GetLocationAtIndex(0)
+
+# Get the address where breakpoint is actually set.
+bpaddr = location.GetLoadAddress()
+
+# Breakpoint address should be adjusted to the address of branch instruction.
+self.assertTrue(branchinstaddress == bpaddr)
+i += 1
+else:
+i += 1
+
+if __name__ == '__main__':
+import atexit
+lldb.SBDebugger.Initialize()
+atexit.register(lambda: lldb.SBDebugger.Terminate())
+unittest2.main()
Index: packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/Makefile
===
--- /dev/null
+++ packages/Python/lldbsuite/test/functionalities/breakpoint/bre
[Lldb-commits] [lldb] r258303 - [RenderScript] New command for viewing coordinate of current kernel invocation
Author: ewancrawford
Date: Wed Jan 20 06:03:29 2016
New Revision: 258303
URL: http://llvm.org/viewvc/llvm-project?rev=258303&view=rev
Log:
[RenderScript] New command for viewing coordinate of current kernel invocation
Patch adds command 'language renderscript kernel coordinate' for printing the
kernel index in (x,y,z) format.
This is done by walking the call stack and looking for a function with suffix
'.expand', as well as the frame variables containing the coordinate data.
Modified:
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h
Modified:
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp?rev=258303&r1=258302&r2=258303&view=diff
==
---
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
(original)
+++
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
Wed Jan 20 06:03:29 2016
@@ -390,6 +390,8 @@ const unsigned int RenderScriptRuntime::
{eFormatVectorOfFloat32, eFormatVectorOfFloat32, sizeof(float) * 4} //
RS_TYPE_MATRIX_2X2
};
+const std::string RenderScriptRuntime::s_runtimeExpandSuffix(".expand");
+const std::array
RenderScriptRuntime::s_runtimeCoordVars{"rsIndex", "p->current.y",
"p->current.z"};
//--
// Static Functions
//--
@@ -3071,6 +3073,79 @@ RenderScriptRuntime::GetFrameVarAsUnsign
return true;
}
+// Function attempts to find the current coordinate of a kernel invocation by
investigating the
+// values of frame variables in the .expand function. These coordinates are
returned via the coord
+// array reference parameter. Returns true if the coordinates could be found,
and false otherwise.
+bool
+RenderScriptRuntime::GetKernelCoordinate(RSCoordinate &coord, Thread
*thread_ptr)
+{
+Log *log(GetLogIfAnyCategoriesSet(LIBLLDB_LOG_LANGUAGE));
+
+if (!thread_ptr)
+{
+if (log)
+log->Printf("%s - Error, No thread pointer", __FUNCTION__);
+
+return false;
+}
+
+// Walk the call stack looking for a function whose name has the suffix
'.expand'
+// and contains the variables we're looking for.
+for (uint32_t i = 0; i < thread_ptr->GetStackFrameCount(); ++i)
+{
+if (!thread_ptr->SetSelectedFrameByIndex(i))
+continue;
+
+StackFrameSP frame_sp = thread_ptr->GetSelectedFrame();
+if (!frame_sp)
+continue;
+
+// Find the function name
+const SymbolContext sym_ctx = frame_sp->GetSymbolContext(false);
+const char *func_name_cstr = sym_ctx.GetFunctionName().AsCString();
+if (!func_name_cstr)
+continue;
+
+if (log)
+log->Printf("%s - Inspecting function '%s'", __FUNCTION__,
func_name_cstr);
+
+// Check if function name has .expand suffix
+std::string func_name(func_name_cstr);
+const int length_difference = func_name.length() -
RenderScriptRuntime::s_runtimeExpandSuffix.length();
+if (length_difference <= 0)
+continue;
+
+const int32_t has_expand_suffix = func_name.compare(length_difference,
+
RenderScriptRuntime::s_runtimeExpandSuffix.length(),
+
RenderScriptRuntime::s_runtimeExpandSuffix);
+
+if (has_expand_suffix != 0)
+continue;
+
+if (log)
+log->Printf("%s - Found .expand function '%s'", __FUNCTION__,
func_name_cstr);
+
+// Get values for variables in .expand frame that tell us the current
kernel invocation
+bool found_coord_variables = true;
+assert(RenderScriptRuntime::s_runtimeCoordVars.size() == coord.size());
+
+for (uint32_t i = 0; i < coord.size(); ++i)
+{
+uint64_t value = 0;
+if (!GetFrameVarAsUnsigned(frame_sp,
RenderScriptRuntime::s_runtimeCoordVars[i], value))
+{
+found_coord_variables = false;
+break;
+}
+coord[i] = value;
+}
+
+if (found_coord_variables)
+return true;
+}
+return false;
+}
+
// Callback when a kernel breakpoint hits and we're looking for a specific
coordinate.
// Baton parameter contains a pointer to the target coordinate we want to
break on.
// Function then checks the .expand frame for the current coordinate and
breaks to user if it matches.
@@ -3086,53 +31
[Lldb-commits] [lldb] r258304 - Enable TestConcurrentEvents on i386 linux
Author: labath
Date: Wed Jan 20 06:09:12 2016
New Revision: 258304
URL: http://llvm.org/viewvc/llvm-project?rev=258304&view=rev
Log:
Enable TestConcurrentEvents on i386 linux
The test has been passing reliably the last 100 runs of the build bot.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentEvents.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentEvents.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentEvents.py?rev=258304&r1=258303&r2=258304&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentEvents.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentEvents.py
Wed Jan 20 06:09:12 2016
@@ -130,7 +130,6 @@ class ConcurrentEventsTestCase(TestBase)
@skipIfFreeBSD # timing out on buildbot
@skipIfRemoteDueToDeadlock
-@expectedFailureAll("llvm.org/pr16714", oslist=["linux"], archs=["i386"])
@expectedFailureAll(archs=['mips64', 'mips64el']) # Atomic sequences are
not supported yet for MIPS in LLDB.
def test_signal_delay_watch(self):
"""Test a (1 second delay) watchpoint and a signal in multiple
threads."""
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r258305 - Enable TestInlineStepping on linux i386
Author: labath
Date: Wed Jan 20 06:17:26 2016
New Revision: 258305
URL: http://llvm.org/viewvc/llvm-project?rev=258305&view=rev
Log:
Enable TestInlineStepping on linux i386
Test has been passing at least the last 200 buildbot runs.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/inline-stepping/TestInlineStepping.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/inline-stepping/TestInlineStepping.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/inline-stepping/TestInlineStepping.py?rev=258305&r1=258304&r2=258305&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/inline-stepping/TestInlineStepping.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/inline-stepping/TestInlineStepping.py
Wed Jan 20 06:17:26 2016
@@ -16,8 +16,6 @@ class TestInlineStepping(TestBase):
@add_test_categories(['pyapi'])
@expectedFailureFreeBSD('llvm.org/pr17214')
@expectedFailureIcc # Not really a bug. ICC combines two inlined
functions.
-# failed 1/365 dosep runs, (i386-clang), TestInlineStepping.py:237 failed
to stop at first breakpoint in main
-@expectedFailureAll(oslist=["linux"], archs=["i386"])
def test_with_python_api(self):
"""Test stepping over and into inlined functions."""
self.build()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r258306 - Fix clang warning in RenderScriptRuntime
Author: labath
Date: Wed Jan 20 06:23:23 2016
New Revision: 258306
URL: http://llvm.org/viewvc/llvm-project?rev=258306&view=rev
Log:
Fix clang warning in RenderScriptRuntime
std::array should have "the same semantics as a struct holding a C-style array
T[N] as its only
non-static data member", so the initialization should have one more level of
braces. Hopefully,
no compiler will object to that.
Modified:
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
Modified:
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp?rev=258306&r1=258305&r2=258306&view=diff
==
---
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
(original)
+++
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
Wed Jan 20 06:23:23 2016
@@ -391,7 +391,7 @@ const unsigned int RenderScriptRuntime::
};
const std::string RenderScriptRuntime::s_runtimeExpandSuffix(".expand");
-const std::array
RenderScriptRuntime::s_runtimeCoordVars{"rsIndex", "p->current.y",
"p->current.z"};
+const std::array
RenderScriptRuntime::s_runtimeCoordVars{{"rsIndex", "p->current.y",
"p->current.z"}};
//--
// Static Functions
//--
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16293: [cmake] Make dependencies of lldb libraries private
labath added a comment. Zachary, could you take a look at this please. I'd like to squeeze this into 3.8 if it is working.. > At some point lldb-argdumper is planned to be reworked just slightly so it > had no dependencies on the lldb core. (That would have avoided this I > suspect.) It would, although I don't see a problem with the argdumper re-using the json parser from lldb (even though the parser is not the public interface of liblldb). The whole LINKER_SUPPORTS_GROUPS thing could be beautified a bit (I might do that afterwards), but otherwise, the whole thing seems reasonable to me. http://reviews.llvm.org/D16293 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r258315 - Mark arm/aarch64 specific xfails with expectedFailureLinux decorator
Author: omjavaid
Date: Wed Jan 20 09:01:54 2016
New Revision: 258315
URL: http://llvm.org/viewvc/llvm-project?rev=258315&view=rev
Log:
Mark arm/aarch64 specific xfails with expectedFailureLinux decorator
This patch marks some known failures and puts on expectedFailureLinux decorator
to have testsuite xfail them.
Affected tests are:
test/functionalities/watchpoint/step_over_watchpoint.py
test/functionalities/watchpoint/watchpoint_set_command/TestWatchLocationWithWatchSet.py
test/tools/lldb-server/TestGdbRemoteSingleStep.py
test/tools/lldb-server/TestGdbRemote_vCont.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_set_command/TestWatchLocationWithWatchSet.py
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteSingleStep.py
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_vCont.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py?rev=258315&r1=258314&r2=258315&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py
Wed Jan 20 09:01:54 2016
@@ -17,7 +17,7 @@ class TestStepOverWatchpoint(TestBase):
return ['basic_process']
@expectedFailureAndroid(archs=['arm', 'aarch64']) # Watchpoints not
supported
-@expectedFailureLinux(bugnumber="llvm.org/pr26031", archs=['arm'])
+@expectedFailureLinux(bugnumber="llvm.org/pr26031", archs=['aarch64',
'arm'])
@expectedFailureWindows("llvm.org/pr24446")
def test(self):
"""Test stepping over watchpoints."""
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_set_command/TestWatchLocationWithWatchSet.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_set_command/TestWatchLocationWithWatchSet.py?rev=258315&r1=258314&r2=258315&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_set_command/TestWatchLocationWithWatchSet.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_set_command/TestWatchLocationWithWatchSet.py
Wed Jan 20 09:01:54 2016
@@ -27,7 +27,7 @@ class WatchLocationUsingWatchpointSetTes
# Build dictionary to have unique executable names for each test
method.
@expectedFailureAndroid(archs=['arm', 'aarch64']) # Watchpoints not
supported
-@expectedFailureLinux(bugnumber="llvm.org/pr26031", archs=['arm'])
+@expectedFailureLinux(bugnumber="llvm.org/pr26031", archs=['aarch64',
'arm'])
@expectedFailureWindows("llvm.org/pr24446") # WINDOWS XFAIL TRIAGE -
Watchpoints not supported on Windows
def test_watchlocation_using_watchpoint_set(self):
"""Test watching a location with 'watchpoint set expression -w write
-s size' option."""
Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteSingleStep.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteSingleStep.py?rev=258315&r1=258314&r2=258315&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteSingleStep.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteSingleStep.py
Wed Jan 20 09:01:54 2016
@@ -17,7 +17,8 @@ class TestGdbRemoteSingleStep(gdbremote_
self.single_step_only_steps_one_instruction(use_Hc_packet=True,
step_instruction="s")
@llgs_test
-@expectedFailureAndroid(bugnumber="llvm.com/pr24739", archs=["arm",
"aarch64"])
+@expectedFailureAndroid(bugnumber="llvm.org/pr24739", archs=["arm",
"aarch64"])
+@expectedFailureLinux(bugnumber="llvm.org/pr24739", archs=["arm",
"aarch64"])
def test_single_step_only_steps_one_instruction_with_s_llgs(self):
self.init_llgs_test()
self.build()
Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_vCont.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_vCont.py?rev=258315&r1=258314&r2=258315&view=diff
==
--
Re: [Lldb-commits] [PATCH] D16293: [cmake] Make dependencies of lldb libraries private
zturner added a comment. I get linker errors on Windows with this. The reason is that Windows doesn't have getopt, but getopt is called from from Driver.cpp and linked into the main lldb executable. Since liblldb is built as a shared library, when the keyword is public it's linking the liblldb inputs into the executable, which works. But when liblldb uses the private keyword, then the inputs don't get fed into lldb.exe and it fails to link. A better solution would involve layering the windows getopt implementation more appropriately so that it could just be linked directly into lldb.exe. But for now, I think you will need to put this keyword change behind an OS flag so that it continues to use public on Windows (perhaps with a comment explaining why this is necessary) http://reviews.llvm.org/D16293 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
zturner added a comment. FWIW, I think Adrian's original point is that testing the behavior of signed types shouldn't depend on step over functionality. It's good practice in general to make tests depend on as little debugger functionality as possibly to reliably test the thing you want to test. Because the more functionality you depend on, the more fickle your test becomes. Why does a bug in one platform's implementation of step over break a test about whether signed ints work? So, I'm all for removing this test's dependency on step-over (TestUnsignedTypes doesn't use step over, for example) if there's a way to reliably test the functionality without step over. But I still think it's important to know what CL broke all these tests. http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
tberghammer added a subscriber: tberghammer. tberghammer added a comment. In http://reviews.llvm.org/D16334#331318, @zturner wrote: > FWIW, I think Adrian's original point is that testing the behavior of signed > types shouldn't depend on step over functionality. It's good practice in > general to make tests depend on as little debugger functionality as possibly > to reliably test the thing you want to test. Because the more functionality > you depend on, the more fickle your test becomes. Why does a bug in one > platform's implementation of step over break a test about whether signed ints > work? > > So, I'm all for removing this test's dependency on step-over > (TestUnsignedTypes doesn't use step over, for example) if there's a way to > reliably test the functionality without step over. > > But I still think it's important to know what CL broke all these tests. In general I agree with your concept of trying to make the tests standalone without depending on a lot of other functionality, but I see a major issue. Currently our test coverage is low even for the basic functionality (backtrace, frame variables, stepping, etc.) and a lot of failure in these areas are detected by completely unrelated tests because they are depending on them and as a result doing some sort of stress testing (each test try a slightly different situation). If we make all of our tests standalone without increasing the number of tests by a lot (I guess 2-5x needed) I expect that we will lose a lot of coverage. I am more happy if an unrelated test fails because we introduced a bug then ending up with a lot more undetected bugs. http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
I sort of agree with this and sort of don't. Formally, I agree with the notion of limited focused tests. But in practice it is often the noise in tests that catches bugs that we don't yet have tests for. And especially when the "noise" is doing things like step over that 100% should work in any functional debugger... So I am also a little leery of cleaning up the tests too much so that they only test the things we've thought to test and miss other things. Jim > On Jan 20, 2016, at 11:08 AM, Zachary Turner wrote: > > zturner added a comment. > > FWIW, I think Adrian's original point is that testing the behavior of signed > types shouldn't depend on step over functionality. It's good practice in > general to make tests depend on as little debugger functionality as possibly > to reliably test the thing you want to test. Because the more functionality > you depend on, the more fickle your test becomes. Why does a bug in one > platform's implementation of step over break a test about whether signed ints > work? > > So, I'm all for removing this test's dependency on step-over > (TestUnsignedTypes doesn't use step over, for example) if there's a way to > reliably test the functionality without step over. > > But I still think it's important to know what CL broke all these tests. > > > http://reviews.llvm.org/D16334 > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
jingham added a comment. I sort of agree with this and sort of don't. Formally, I agree with the notion of limited focused tests. But in practice it is often the noise in tests that catches bugs that we don't yet have tests for. And especially when the "noise" is doing things like step over that 100% should work in any functional debugger... So I am also a little leery of cleaning up the tests too much so that they only test the things we've thought to test and miss other things. Jim http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
zturner added a comment. In http://reviews.llvm.org/D16334#331338, @jingham wrote: > I sort of agree with this and sort of don't. Formally, I agree with the > notion of limited focused tests. But in practice it is often the noise in > tests that catches bugs that we don't yet have tests for. And especially > when the "noise" is doing things like step over that 100% should work in any > functional debugger... So I am also a little leery of cleaning up the tests > too much so that they only test the things we've thought to test and miss > other things. > > Jim I think we should solve that by adding more tests though. I mean I don't want to do a 1 step forward, 2 steps back kind of thing. If someone knows of an area where we're missing coverage, then stop what you're doing and go add the coverage. If it's the type of thing where we don't know we're missing coverage and we're just hoping an unrelated test catches it someday, I don't agree with that. Just because we know we have a problem doesn't mean we should solve it the wrong way, because then we can never possibly reach the desired end state since we're actively moving farther away from it. http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
zturner added a comment. For example, what if someone adds a test that uses a very small amount of functionality but tests the thing it's supposed to test. Do we block the change and say "please make this test more complicated, we want to test as much stuff as possible"? Of course not. It's ridiculous right? It sounds like at least 2 people on this thread know of specific areas where we're lacking test coverage. Why not spend a few days doing nothing but improving test coverage? http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
I think to get a very good coverage for the basic functionalities we need some sort of stress testing or fuzzing infrastructure because the most issues I hit come from compilers generating something a bit different then we are expecting. For stack unwinding I added a stress test (TestStandardUnwind.py, working on arm and aarch64) what catches a lot of bugs but running it takes so long that it can't be added to the everyday test suit. Should we try to design a fuzz testing infrastructure what runs on a build bot so we don't have to depend on the fuzz testing behavior of the normal test suit? On Wed, Jan 20, 2016 at 7:22 PM Zachary Turner wrote: > zturner added a comment. > > In http://reviews.llvm.org/D16334#331338, @jingham wrote: > > > I sort of agree with this and sort of don't. Formally, I agree with the > notion of limited focused tests. But in practice it is often the noise in > tests that catches bugs that we don't yet have tests for. And especially > when the "noise" is doing things like step over that 100% should work in > any functional debugger... So I am also a little leery of cleaning up the > tests too much so that they only test the things we've thought to test and > miss other things. > > > > Jim > > > I think we should solve that by adding more tests though. I mean I don't > want to do a 1 step forward, 2 steps back kind of thing. If someone knows > of an area where we're missing coverage, then stop what you're doing and go > add the coverage. If it's the type of thing where we don't know we're > missing coverage and we're just hoping an unrelated test catches it > someday, I don't agree with that. Just because we know we have a problem > doesn't mean we should solve it the wrong way, because then we can never > possibly reach the desired end state since we're actively moving farther > away from it. > > > http://reviews.llvm.org/D16334 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
tberghammer added a comment. I think to get a very good coverage for the basic functionalities we need some sort of stress testing or fuzzing infrastructure because the most issues I hit come from compilers generating something a bit different then we are expecting. For stack unwinding I added a stress test (TestStandardUnwind.py, working on arm and aarch64) what catches a lot of bugs but running it takes so long that it can't be added to the everyday test suit. Should we try to design a fuzz testing infrastructure what runs on a build bot so we don't have to depend on the fuzz testing behavior of the normal test suit? http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
> On Jan 20, 2016, at 11:25 AM, Zachary Turner wrote: > > zturner added a comment. > > For example, what if someone adds a test that uses a very small amount of > functionality but tests the thing it's supposed to test. Do we block the > change and say "please make this test more complicated, we want to test as > much stuff as possible"? Of course not. It's ridiculous right? > Indeed that is silly. But not much sillier than "don't add a step to that test because you aren't covering step explicitly in this test..." > It sounds like at least 2 people on this thread know of specific areas where > we're lacking test coverage. Why not spend a few days doing nothing but > improving test coverage? > Don't think I was claiming to KNOW where we are missing test coverage. I'm simply saying that in my past experience both with the lldb & gdb test suites we often catch bugs because of failures in a part of a test that was not essential to the test being run. That's because the debugger is not like something like a compiler, where you feed in some input and it proceeds regularly through a machine to spit some output at the end. The debugger keeps a lot more state over multiple operations, so you can get bugs that are because you did A then B rather than B then A, or A after B, etc. That's just the nature of the thing. So some amount of fuzziness is really helpful for catching these sort of interactions. Jim > > http://reviews.llvm.org/D16334 > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
amccarth added a comment. By having tests doing too much, we get problems like this (where ~12 seemingly unrelated tests started failing over the holiday weekend) instead of one test that points to the root cause. (In this case, we're still looking for the root cause of the regression. A simple bisect doesn't help because we have separate repos for LLVM, clang, and lldb.) http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
zturner added a comment. I don't know, I still disagree. If something in step-over breaks, I dont' want to dig through a list of 30 other tests that have nothing to do with the problem, only to find out 2 days later that the problem is actually in step over. The only reason this helps is because the test suite is insufficient as it is. But it doesn't need to be! The real solution is for people to start thinking about tests more. I've hounded on this time and time again, but it seems most of the time tests only get added when I catch a CL go by with no tests and request them. Sometimes they don't even get added then. "Oh yea this is on my radar, I'll loop back around to it." . Hundreds of CLs have gone in over the past few months, and probably 10 tests have gone in. *That's* the problem. People should be spending as much time thinking about how to write tests as they are about how to write the thing they're implementing. Almost every CL can be tested. Everything, no matter how small, can be tested. If the SB tests are too heavyweight, that's what the unit tests are for. IF there's no SB API that does what you need to do to test it, add the SB API. "But I have to design the API first" is not an excuse. Design it then. We've got an entire class of feature that "can't be tested" (the unwinder). There's like 0 unwinding tests. I get that it's hard, but writing a debugger is hard too, and you guys did it. I do not believe that we can't write better tests. Or unwinder tests. Or core-file debugging tests. Really, the solution is for people to stop chekcing in CLs with no tests, and for people to spend as much time writing their tests as they do the rest of their CLs. If the problem is that people don't have the time because they've got too much other stuff on their plate, that's not a good excuse and I don't think we should intentionally encourage writing poor tests just because someone's manager doesn't give them enough time to do things the right way. http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
On Wed, Jan 20, 2016 at 11:48 AM Zachary Turner wrote: > > If the problem is that people don't have the time because they've got too > much other stuff on their plate, that's not a good excuse and I don't think > we should intentionally encourage writing poor tests just because someone's > manager doesn't give them enough time to do things the right way. > Replace "someone's manager" with "the power's that be". I didn't mean to sound like I was directing this at anyone in particular. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
Perhaps a middle ground to these two sides could be something along the lines of "If you're going to make sweeping changes to remove a particular feature from a set of tests, make sure there's a reasonable amount of isolated coverage of the thing you're removing". Honestly though, our culture of testing really needs to imrpove at the larger scale going forward. We need more tests, and we need to start blocking or reverting CLs that don't have some amount test coverage. A common one that I see is "well this is just putting some infrastructure in place that isn't being used anywhere yet". But even that is still testable. That's exactly what unit tests, mock implementations, and dependency injection are for. On Wed, Jan 20, 2016 at 11:57 AM Zachary Turner wrote: > On Wed, Jan 20, 2016 at 11:48 AM Zachary Turner > wrote: > >> >> If the problem is that people don't have the time because they've got too >> much other stuff on their plate, that's not a good excuse and I don't think >> we should intentionally encourage writing poor tests just because someone's >> manager doesn't give them enough time to do things the right way. >> > > Replace "someone's manager" with "the power's that be". I didn't mean to > sound like I was directing this at anyone in particular. > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
tberghammer added a comment. In http://reviews.llvm.org/D16334#331368, @zturner wrote: > I don't know, I still disagree. If something in step-over breaks, I dont' > want to dig through a list of 30 other tests that have nothing to do with the > problem, only to find out 2 days later that the problem is actually in step > over. The only reason this helps is because the test suite is insufficient > as it is. But it doesn't need to be! I agree but first we should fix the test coverage and then fix the individual tests. Doing it in the opposite way will cause a significant drop in quality (we will fix individual tests but not increase the coverage enough). > The real solution is for people to start thinking about tests more. I've > hounded on this time and time again, but it seems most of the time tests only > get added when I catch a CL go by with no tests and request them. Sometimes > they don't even get added then. "Oh yea this is on my radar, I'll loop back > around to it." . Hundreds of CLs have gone in over > the past few months, and probably 10 tests have gone in. *That's* the > problem. People should be spending as much time thinking about how to write > tests as they are about how to write the thing they're implementing. Almost > every CL can be tested. Everything, no matter how small, can be tested. If > the SB tests are too heavyweight, that's what the unit tests are for. IF > there's no SB API that does what you need to do to test it, add the SB API. > "But I have to design the API first" is not an excuse. Design it then. I think we need a different API for tests then the SB API which can be changed more freely without have to worry about backward compatibility. When adding a new feature I try to avoid adding an SB API until I know for sure what data I have to expose because a wrong decision early on will carry forward (how many deprecated SB API calls we have?). > We've got an entire class of feature that "can't be tested" (the unwinder). > There's like 0 unwinding tests. I get that it's hard, but writing a debugger > is hard too, and you guys did it. I do not believe that we can't write > better tests. Or unwinder tests. Or core-file debugging tests. > > Really, the solution is for people to stop chekcing in CLs with no tests, and > for people to spend as much time writing their tests as they do the rest of > their CLs. If the problem is that people don't have the time because they've > got too much other stuff on their plate, that's not a good excuse and I don't > think we should intentionally encourage writing poor tests just because > someone's manager doesn't give them enough time to do things the right way. It is true that every CL can be tested but a lot of change is going in to address a specific edge case generated by a specific compiler in a strange situation. To create a reliable test from it we have to commit in a compiled binary with the strange/incorrect debug info and then it will be a platform and architecture specific test what is also very hard to debug because you most likely can't recompile it with your own compiler. I am not sure we want to go down in this road. http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
zturner added a subscriber: zturner. zturner added a comment. Perhaps a middle ground to these two sides could be something along the lines of "If you're going to make sweeping changes to remove a particular feature from a set of tests, make sure there's a reasonable amount of isolated coverage of the thing you're removing". Honestly though, our culture of testing really needs to imrpove at the larger scale going forward. We need more tests, and we need to start blocking or reverting CLs that don't have some amount test coverage. A common one that I see is "well this is just putting some infrastructure in place that isn't being used anywhere yet". But even that is still testable. That's exactly what unit tests, mock implementations, and dependency injection are for. http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
zturner added a comment. In http://reviews.llvm.org/D16334#331420, @tberghammer wrote: > In http://reviews.llvm.org/D16334#331368, @zturner wrote: > > > I don't know, I still disagree. If something in step-over breaks, I dont' > > want to dig through a list of 30 other tests that have nothing to do with > > the problem, only to find out 2 days later that the problem is actually in > > step over. The only reason this helps is because the test suite is > > insufficient as it is. But it doesn't need to be! > > > I agree but first we should fix the test coverage and then fix the individual > tests. Doing it in the opposite way will cause a significant drop in quality > (we will fix individual tests but not increase the coverage enough). > > > The real solution is for people to start thinking about tests more. I've > > hounded on this time and time again, but it seems most of the time tests > > only get added when I catch a CL go by with no tests and request them. > > Sometimes they don't even get added then. "Oh yea this is on my radar, > > I'll loop back around to it." . Hundreds of CLs > > have gone in over the past few months, and probably 10 tests have gone in. > > *That's* the problem. People should be spending as much time thinking > > about how to write tests as they are about how to write the thing they're > > implementing. Almost every CL can be tested. Everything, no matter how > > small, can be tested. If the SB tests are too heavyweight, that's what the > > unit tests are for. IF there's no SB API that does what you need to do to > > test it, add the SB API. "But I have to design the API first" is not an > > excuse. Design it then. > > > I think we need a different API for tests then the SB API which can be > changed more freely without have to worry about backward compatibility. When > adding a new feature I try to avoid adding an SB API until I know for sure > what data I have to expose because a wrong decision early on will carry > forward (how many deprecated SB API calls we have?). Do you have a concrete example of where you don't want to add an SB API, but a unit test isn't ideal? http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D16334: Fix TestSignedTypes.py by removing a bogus step-over
zturner added a comment. In http://reviews.llvm.org/D16334#331420, @tberghammer wrote: > It is true that every CL can be tested but a lot of change is going in to > address a specific edge case generated by a specific compiler in a strange > situation. To create a reliable test from it we have to commit in a compiled > binary with the strange/incorrect debug info and then it will be a platform > and architecture specific test what is also very hard to debug because you > most likely can't recompile it with your own compiler. I am not sure we want > to go down in this road. You can test cases like this easily with unit tests and dependency injection. Just make a mock interface that returns the exact values you need when queried for certain symbols or whatever. http://reviews.llvm.org/D16334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] Buildbot numbers for week of 1/10/2016 - 1/16/2016
Hello everyone, Below are some buildbot numbers for the last week of 1/10/2016 - 1/16/2016. Thanks Galina Number of commits by project: project | commits ---+--- llvm | 391 cfe | 100 lldb |56 lld |46 compiler-rt |30 libcxx| 9 clang-tools-extra | 7 polly | 6 openmp| 4 libcxxabi | 2 ---+--- 651 Number of completed builds, failed builds and average build time for successful builds per active builder: buildername | completed | failed | time ---+++ clang-aarch64-lnt | 58 | 4 | 02:41:05 clang-atom-d525-fedora| 17 | 1 | 09:07:26 clang-atom-d525-fedora-rel| 66 | 5 | 02:18:25 clang-bpf-build |365 | 17 | 00:03:20 clang-cmake-aarch64-42vma |164 | 15 | 00:45:10 clang-cmake-aarch64-full | 42 | 12 | 03:56:57 clang-cmake-aarch64-quick |194 | 7 | 00:30:23 clang-cmake-armv7-a15 |180 | 12 | 00:35:19 clang-cmake-armv7-a15-full| 77 | 4 | 01:47:18 clang-cmake-armv7-a15-selfhost| 41 | 12 | 04:31:57 clang-cmake-armv7-a15-selfhost-neon | 31 | 9 | 05:37:14 clang-cmake-mips | 76 | 6 | 01:20:24 clang-cmake-mipsel| 18 | 2 | 07:07:43 clang-cmake-thumbv7-a15 |191 | 16 | 00:33:22 clang-cmake-thumbv7-a15-full-sh | 26 | 6 | 06:45:59 clang-hexagon-elf |263 | 14 | 00:18:25 clang-native-aarch64-full | 10 | 3 | 14:30:53 clang-native-arm-lnt | 67 | 1 | 01:39:08 clang-native-arm-lnt-perf | 16 || 09:15:46 clang-ppc64-elf-linux | 87 | 6 | 01:34:19 clang-ppc64-elf-linux2|152 | 33 | 00:40:29 clang-sphinx-docs |110 || 00:00:22 clang-x64-ninja-win7 |195 | 77 | 00:36:55 clang-x86-win2008-selfhost|125 | 60 | 01:14:15 clang-x86_64-darwin13-cross-arm |262 | 13 | 00:20:16 clang-x86_64-darwin13-cross-mingw32 |237 | 7 | 00:23:59 clang-x86_64-debian-fast |144 | 9 | 00:14:07 clang-x86_64-linux-abi-test |388 | 11 | 00:09:59 clang-x86_64-linux-selfhost-modules |305 | 75 | 00:16:17 clang-x86_64-ubuntu-gdb-75|113 | 64 | 00:49:48 libcxx-libcxxabi-arm-linux| 10 || 01:08:11 libcxx-libcxxabi-singlethreaded-x86_64-linux-debian | 8 || 00:10:42 libcxx-libcxxabi-x86_64-linux-debian | 8 || 00:11:06 libcxx-libcxxabi-x86_64-linux-debian-noexceptions | 8 | 3 | 00:10:49 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 9 | 9 | libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03| 9 | 1 | 00:06:14 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 11 || 00:06:19 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 11 || 00:06:29 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z| 10 || 00:06:56 libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 8 | 8 | libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 11 || 00:13:43 libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi | 11 || 00:07:27 libcxx-sphinx-docs| 11 || 00:00:17 libomp-clang-x86_64-linux-debian |
[Lldb-commits] [lldb] r258365 - Fixed some #ifdefs. We were erroneously not supporting certain simulators.
Author: spyffe Date: Wed Jan 20 17:12:39 2016 New Revision: 258365 URL: http://llvm.org/viewvc/llvm-project?rev=258365&view=rev Log: Fixed some #ifdefs. We were erroneously not supporting certain simulators. We had some #ifdefs that were looking for the wrong #defines and as a result debugserver didn't have support for certain simulators. This patch resolves the problem. Modified: lldb/trunk/tools/debugserver/source/RNBRemote.cpp Modified: lldb/trunk/tools/debugserver/source/RNBRemote.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/RNBRemote.cpp?rev=258365&r1=258364&r2=258365&view=diff == --- lldb/trunk/tools/debugserver/source/RNBRemote.cpp (original) +++ lldb/trunk/tools/debugserver/source/RNBRemote.cpp Wed Jan 20 17:12:39 2016 @@ -5863,7 +5863,7 @@ RNBRemote::HandlePacket_qProcessInfo (co DNBLogThreadedIf (LOG_RNB_PROC, "LC_VERSION_MIN_MACOSX -> 'ostype:macosx;'"); break; -#if defined (TARGET_OS_TV) && TARGET_OS_TV == 1 +#if defined (LC_VERSION_MIN_TVOS) case LC_VERSION_MIN_TVOS: os_handled = true; rep << "ostype:tvos;"; @@ -5871,7 +5871,7 @@ RNBRemote::HandlePacket_qProcessInfo (co break; #endif -#if defined (TARGET_OS_WATCH) && TARGET_OS_WATCH == 1 +#if defined (LC_VERSION_MIN_WATCHOS) case LC_VERSION_MIN_WATCHOS: os_handled = true; rep << "ostype:watchos;"; ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r258367 - Fix a problem where we were not calling fcntl() with the correct arguments for F_DUPFD
Author: enrico Date: Wed Jan 20 17:20:10 2016 New Revision: 258367 URL: http://llvm.org/viewvc/llvm-project?rev=258367&view=rev Log: Fix a problem where we were not calling fcntl() with the correct arguments for F_DUPFD On Mac OS X, this was working just fine in debug builds (presumably, because the right value ended up being at the right location for the variadic ABI), but not in Release builds As a result, we were seeing failures with commands that set their own immediate output stream - only in Release builds, which always makes for a fun little investigation I have removed those fcntl() calls and replaced them with dup() calls. This fixes the issue in both Debug and Release builds Modified: lldb/trunk/source/Host/common/File.cpp Modified: lldb/trunk/source/Host/common/File.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/common/File.cpp?rev=258367&r1=258366&r2=258367&view=diff == --- lldb/trunk/source/Host/common/File.cpp (original) +++ lldb/trunk/source/Host/common/File.cpp Wed Jan 20 17:20:10 2016 @@ -191,7 +191,7 @@ File::GetStream () #ifdef _WIN32 m_descriptor = ::_dup(GetDescriptor()); #else -m_descriptor = ::fcntl(GetDescriptor(), F_DUPFD); +m_descriptor = dup(GetDescriptor()); #endif m_should_close_fd = true; } @@ -237,7 +237,7 @@ File::Duplicate (const File &rhs) #ifdef _WIN32 m_descriptor = ::_dup(rhs.GetDescriptor()); #else -m_descriptor = ::fcntl(rhs.GetDescriptor(), F_DUPFD); +m_descriptor = dup(rhs.GetDescriptor()); #endif if (!DescriptorIsValid()) error.SetErrorToErrno(); ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r258387 - When ObjectFileMachO reads a Mach-O file for a 32-bit arm cpu,
Author: jmolenda
Date: Wed Jan 20 22:38:05 2016
New Revision: 258387
URL: http://llvm.org/viewvc/llvm-project?rev=258387&view=rev
Log:
When ObjectFileMachO reads a Mach-O file for a 32-bit arm cpu,
set the triple's "vendor" field to Apple.
We don't want to assume a vendor of Apple for all Mach-O files -
this breaks x86_64 EFI debugging where they put non-Apple binaries
in a Mach-O format for ease of handling.
But on armv7, Apple's ABI always uses r7 as the frame pointer
register; if we don't set the Vendor field to Apple, we can pick
up a generic armv7 ABI where the fp is r11 (or r7 for thumb) which
breaks backtracing altogether.
Greg is reluctant for us to make any assumptions about the Vendor
here, but we'll see how this shakes out. It's such a big problem
on armv7 if we don't know this is using the Apple ABI that it's worth
trying this approach.
Modified:
lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
Modified: lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp?rev=258387&r1=258386&r2=258387&view=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp Wed Jan 20
22:38:05 2016
@@ -4828,9 +4828,22 @@ ObjectFileMachO::GetArchitecture (const
if (header.filetype == MH_PRELOAD)
{
-// Set vendor to an unspecified unknown or a "*" so it can match
any vendor
-triple.setVendor(llvm::Triple::UnknownVendor);
-triple.setVendorName(llvm::StringRef());
+if (header.cputype == CPU_TYPE_ARM)
+{
+// If this is a 32-bit arm binary, and it's a standalone
binary,
+// force the Vendor to Apple so we don't accidentally pick up
+// the generic armv7 ABI at runtime. Apple's armv7 ABI always
uses
+// r7 for the frame pointer register; most other armv7 ABIs
use a
+// combination of r7 and r11.
+triple.setVendor(llvm::Triple::Apple);
+}
+else
+{
+// Set vendor to an unspecified unknown or a "*" so it can
match any vendor
+// This is required for correct behavior of EFI debugging on
x86_64
+triple.setVendor(llvm::Triple::UnknownVendor);
+triple.setVendorName(llvm::StringRef());
+}
return true;
}
else
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
