Re: [Lldb-commits] [PATCH] D15067: Design building out of sources
labath resigned from this revision. labath removed a reviewer: labath. labath added a comment. I am cleaning out my review queue. Feel free to add me back when you want to get this moving again... Repository: rL LLVM http://reviews.llvm.org/D15067 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15241: Simplify TestThreadSpecificBreakpoint.py
labath closed this revision. labath added a comment. This was committed ages ago. http://reviews.llvm.org/D15241 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D15834: Handle hardcoded breakpoints on Windows (e.g., int3 or __debugbreak())
labath closed this revision. labath added a comment. This was committed ages ago. http://reviews.llvm.org/D15834 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D17022: [LLDB][MIPS] Provide CPU string to compiler for appropriate code generation for MIPS
bhushan added a comment. Hi @zturner, Can you please "accept" this revision so that I can "close" this one? Repository: rL LLVM http://reviews.llvm.org/D17022 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r263544 - Fix expression evaluation for resolving anonymous aggregrate types with a typedefed name
Author: ewancrawford
Date: Tue Mar 15 04:50:16 2016
New Revision: 263544
URL: http://llvm.org/viewvc/llvm-project?rev=263544&view=rev
Log:
Fix expression evaluation for resolving anonymous aggregrate types with a
typedefed name
This fixes a recently reported a
bug(https://llvm.org/bugs/show_bug.cgi?id=26790) relating to the clang
expression evaluator no longer being able to resolve calls to
functions with arguments to typedefed anonymous structs, unions, or enums after
a cleanup to the expression parsing code in r260768
This fixes the issue by attaching the tagged name to the original
clang::TagDecl object when generating the typedef in
lldb::ClangAstContext::CreateTypeDef.
This also fixes the issue for anonymous typedefs for non-struct types (unions
and enums) where we have a tag name.
Author: Luke Drummond
Differential Revision: http://reviews.llvm.org/D18099
Modified:
lldb/trunk/source/Symbol/ClangASTContext.cpp
Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=263544&r1=263543&r2=263544&view=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Tue Mar 15 04:50:16 2016
@@ -4640,6 +4640,20 @@ ClangASTContext::CreateTypedef (lldb::op
&clang_ast->Idents.get(typedef_name),
clang_ast->getTrivialTypeSourceInfo(qual_type));
+clang::TagDecl *tdecl = nullptr;
+if (!qual_type.isNull())
+{
+if (const clang::RecordType *rt =
qual_type->getAs())
+tdecl = rt->getDecl();
+if (const clang::EnumType *et =
qual_type->getAs())
+tdecl = et->getDecl();
+}
+
+// Check whether this declaration is an anonymous struct, union, or
enum, hidden behind a typedef. If so, we
+// try to check whether we have a typedef tag to attach to the
original record declaration
+if (tdecl && !tdecl->getIdentifier() &&
!tdecl->getTypedefNameForAnonDecl())
+tdecl->setTypedefNameForAnonDecl(decl);
+
decl->setAccess(clang::AS_public); // TODO respect proper access
specifier
// Get a uniqued clang::QualType for the typedef decl type
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D18176: Fix thread/process ID reading from linux core files
labath created this revision.
labath added a reviewer: zturner.
labath added a subscriber: lldb-commits.
This also adds a basic smoke test for linux core file reading. I'm checking in
the core files as
well, so that the tests can run on all platforms. With some tricks I was able
to produce
reasonably-sized core files (~40K).
This fixes the first part of pr26322.
http://reviews.llvm.org/D18176
Files:
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/i386.core
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/i386.out
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/main.c
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/make-core.sh
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/x86_64.core
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/x86_64.out
source/Plugins/Process/elf-core/ProcessElfCore.cpp
Index: source/Plugins/Process/elf-core/ProcessElfCore.cpp
===
--- source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -559,19 +559,19 @@
have_prstatus = true;
prstatus.Parse(note_data, arch);
thread_data->signo = prstatus.pr_cursig;
+thread_data->tid = prstatus.pr_pid;
header_size = ELFLinuxPrStatus::GetSize(arch);
len = note_data.GetByteSize() - header_size;
thread_data->gpregset = DataExtractor(note_data, header_size, len);
-// FIXME: Obtain actual tid on Linux
-thread_data->tid = m_thread_data.size();
break;
case NT_FPREGSET:
thread_data->fpregset = note_data;
break;
case NT_PRPSINFO:
have_prpsinfo = true;
prpsinfo.Parse(note_data, arch);
thread_data->name = prpsinfo.pr_fname;
+SetID(prpsinfo.pr_pid);
break;
case NT_AUXV:
m_auxv = DataExtractor(note_data);
Index: packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/make-core.sh
===
--- /dev/null
+++ packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/make-core.sh
@@ -0,0 +1,32 @@
+#! /bin/bash
+
+set -e -x
+
+if grep -q '^|' smaller core files.
+exec ./a.out
Index: packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/main.c
===
--- /dev/null
+++ packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/main.c
@@ -0,0 +1,17 @@
+static void bar(char *boom)
+{
+char F = 'b';
+*boom = 47; // Frame bar
+}
+
+static void foo(char *boom, void (*boomer)(char *))
+{
+char F = 'f';
+boomer(boom); // Frame foo
+}
+
+void _start(void)
+{
+char F = '_';
+foo(0, bar); // Frame _start
+}
Index: packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
===
--- /dev/null
+++ packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
@@ -0,0 +1,45 @@
+"""
+Test basics of linux core file debugging.
+"""
+
+from __future__ import print_function
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class LinuxCoreTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@skipIf(bugnumber="llvm.org/pr26947")
+@no_debug_info_test
+def test_i386(self):
+"""Test that lldb can read the process information from an i386 linux core file."""
+self.do_test("i386", 32306)
+
+@no_debug_info_test
+def test_x86_64(self):
+"""Test that lldb can read the process information from an x86_64 linux core file."""
+self.do_test("x86_64", 32259)
+
+def do_test(self, arch, pid):
+target = self.dbg.CreateTarget(arch + ".out")
+process = target.LoadCore(arch + ".core")
+self.assertTrue(process, PROCESS_IS_VALID)
+self.assertEqual(process.GetNumThreads(), 1)
+self.assertEqual(process.GetProcessID(), pid)
+
+thread = process.GetSelectedThread()
+self.assertTrue(thread)
+self.assertEqual(thread.GetThreadID(), pid)
+backtrace = ["bar", "foo", "_start"]
+self.assertEqual(thread.GetNumFrames(), len(backtrace))
+for i in range(len(backtrace)):
+frame = thread.GetFrameAtIndex(i)
+self.assertTrue(frame)
+self.assertEqual(frame.GetFunctionName(), backtrace[
Re: [Lldb-commits] [PATCH] D17777: Add regression test for expressions calling functions taking anonymous struct typedef arguments
This revision was automatically updated to reflect the committed changes.
Closed by commit rL263547: Add regression test for expressions calling
functions taking anonymous struct… (authored by EwanCrawford).
Changed prior to commit:
http://reviews.llvm.org/D1?vs=49524&id=50719#toc
Repository:
rL LLVM
http://reviews.llvm.org/D1
Files:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/Makefile
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/main.cpp
Index:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
===
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
@@ -0,0 +1,40 @@
+"""
+Test calling user defined functions using expression evaluation.
+This test checks that typesystem lookup works correctly for typedefs of
+untagged structures.
+
+Ticket: https://llvm.org/bugs/show_bug.cgi?id=26790
+"""
+
+from __future__ import print_function
+
+import lldb
+
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestExprLookupAnonStructTypedef(TestBase):
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+TestBase.setUp(self)
+# Find the breakpoint
+self.line = line_number('main.cpp', '// lldb testsuite break')
+
+def test(self):
+"""Test typedeffed untagged struct arguments for function call
expressions"""
+self.build()
+
+self.runCmd("file a.out", CURRENT_EXECUTABLE_SET)
+lldbutil.run_break_set_by_file_and_line(
+self,
+"main.cpp",
+self.line,
+num_expected_locations=-1,
+loc_exact=True
+)
+
+self.runCmd("run", RUN_SUCCEEDED)
+self.expect("expr multiply(&s)", substrs=['$0 = 1'])
Index:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/Makefile
===
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/Makefile
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/Makefile
@@ -0,0 +1,12 @@
+LEVEL = ../../make
+
+CXX_SOURCES := main.cpp
+
+# clang-3.5+ outputs FullDebugInfo by default for Darwin/FreeBSD
+# targets. Other targets do not, which causes this test to fail.
+# This flag enables FullDebugInfo for all targets.
+ifneq (,$(findstring clang,$(CC)))
+ CFLAGS_EXTRAS += -fno-limit-debug-info
+endif
+
+include $(LEVEL)/Makefile.rules
Index:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/main.cpp
===
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/main.cpp
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/main.cpp
@@ -0,0 +1,26 @@
+#include
+
+typedef struct {
+float f;
+int i;
+} my_untagged_struct;
+
+double multiply(my_untagged_struct *s)
+{
+return s->f * s->i;
+}
+
+double multiply(my_untagged_struct *s, int x)
+{
+return multiply(s) * x;
+}
+
+int main(int argc, char **argv)
+{
+my_untagged_struct s = {
+.f = (float)argc,
+.i = argc,
+};
+// lldb testsuite break
+return !(multiply(&s, argc) == pow(argc, 3));
+}
Index: lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
+++ lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
@@ -0,0 +1,40 @@
+"""
+Test calling user defined functions using expression evaluation.
+This test checks that typesystem lookup works correctly for typedefs of
+untagged structures.
+
+Ticket: https://llvm.org/bugs/show_bug.cgi?id=26790
+"""
+
+from __future__ import print_function
+
+import lldb
+
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestExprLookupAnonStructTypedef(TestBase):
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+TestBase.setUp(self)
+# Find the breakpoint
+self.line = line_number('main.cpp', '// lldb testsuite break')
+
+def test(self):
+"""Test typedeffed untagged struct arguments for function call expressions"""
+self.build()
+
+self.runCmd("file a.out", CURRENT_EXECUT
[Lldb-commits] [lldb] r263547 - Add regression test for expressions calling functions taking anonymous struct typedef arguments
Author: ewancrawford
Date: Tue Mar 15 08:02:11 2016
New Revision: 263547
URL: http://llvm.org/viewvc/llvm-project?rev=263547&view=rev
Log:
Add regression test for expressions calling functions taking anonymous struct
typedef arguments
This CL adds a regression test for the bug listed at
https://llvm.org/bugs/show_bug.cgi?id=26790
Functionality was implemented in commit r263544
Author: Luke Drummond
Differential Revision: http://reviews.llvm.org/D1
Added:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/Makefile
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/main.cpp
Added:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/Makefile
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/Makefile?rev=263547&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/Makefile
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/Makefile
Tue Mar 15 08:02:11 2016
@@ -0,0 +1,12 @@
+LEVEL = ../../make
+
+CXX_SOURCES := main.cpp
+
+# clang-3.5+ outputs FullDebugInfo by default for Darwin/FreeBSD
+# targets. Other targets do not, which causes this test to fail.
+# This flag enables FullDebugInfo for all targets.
+ifneq (,$(findstring clang,$(CC)))
+ CFLAGS_EXTRAS += -fno-limit-debug-info
+endif
+
+include $(LEVEL)/Makefile.rules
Added:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py?rev=263547&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
Tue Mar 15 08:02:11 2016
@@ -0,0 +1,40 @@
+"""
+Test calling user defined functions using expression evaluation.
+This test checks that typesystem lookup works correctly for typedefs of
+untagged structures.
+
+Ticket: https://llvm.org/bugs/show_bug.cgi?id=26790
+"""
+
+from __future__ import print_function
+
+import lldb
+
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestExprLookupAnonStructTypedef(TestBase):
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+TestBase.setUp(self)
+# Find the breakpoint
+self.line = line_number('main.cpp', '// lldb testsuite break')
+
+def test(self):
+"""Test typedeffed untagged struct arguments for function call
expressions"""
+self.build()
+
+self.runCmd("file a.out", CURRENT_EXECUTABLE_SET)
+lldbutil.run_break_set_by_file_and_line(
+self,
+"main.cpp",
+self.line,
+num_expected_locations=-1,
+loc_exact=True
+)
+
+self.runCmd("run", RUN_SUCCEEDED)
+self.expect("expr multiply(&s)", substrs=['$0 = 1'])
Added:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/main.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/main.cpp?rev=263547&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/main.cpp
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/main.cpp
Tue Mar 15 08:02:11 2016
@@ -0,0 +1,26 @@
+#include
+
+typedef struct {
+float f;
+int i;
+} my_untagged_struct;
+
+double multiply(my_untagged_struct *s)
+{
+return s->f * s->i;
+}
+
+double multiply(my_untagged_struct *s, int x)
+{
+return multiply(s) * x;
+}
+
+int main(int argc, char **argv)
+{
+my_untagged_struct s = {
+.f = (float)argc,
+.i = argc,
+};
+// lldb testsuite break
+return !(multiply(&s, argc) == pow(argc, 3));
+}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D18188: Move OperatingSystem plugins to SystemInitializerFull
labath created this revision. labath added a reviewer: zturner. labath added a subscriber: lldb-commits. These are not needed in lldb-server. Removing them shrinks the server size by about 1.5%. http://reviews.llvm.org/D18188 Files: source/API/SystemInitializerFull.cpp source/Initialization/SystemInitializerCommon.cpp Index: source/Initialization/SystemInitializerCommon.cpp === --- source/Initialization/SystemInitializerCommon.cpp +++ source/Initialization/SystemInitializerCommon.cpp @@ -25,8 +25,6 @@ #include "Plugins/ObjectContainer/Universal-Mach-O/ObjectContainerUniversalMachO.h" #include "Plugins/ObjectFile/ELF/ObjectFileELF.h" #include "Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h" -#include "Plugins/OperatingSystem/Python/OperatingSystemPython.h" -#include "Plugins/OperatingSystem/Go/OperatingSystemGo.h" #include "Plugins/Platform/Android/PlatformAndroid.h" #include "Plugins/Platform/FreeBSD/PlatformFreeBSD.h" #include "Plugins/Platform/Kalimba/PlatformKalimba.h" @@ -145,10 +143,6 @@ #if defined(_MSC_VER) ProcessWindowsLog::Initialize(); #endif -#ifndef LLDB_DISABLE_PYTHON -OperatingSystemPython::Initialize(); -#endif -OperatingSystemGo::Initialize(); } void @@ -189,11 +183,6 @@ ProcessWindowsLog::Terminate(); #endif -#ifndef LLDB_DISABLE_PYTHON -OperatingSystemPython::Terminate(); -#endif -OperatingSystemGo::Terminate(); - HostInfo::Terminate(); Log::Terminate(); } Index: source/API/SystemInitializerFull.cpp === --- source/API/SystemInitializerFull.cpp +++ source/API/SystemInitializerFull.cpp @@ -57,6 +57,8 @@ #include "Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h" #include "Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h" #include "Plugins/MemoryHistory/asan/MemoryHistoryASan.h" +#include "Plugins/OperatingSystem/Python/OperatingSystemPython.h" +#include "Plugins/OperatingSystem/Go/OperatingSystemGo.h" #include "Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h" #include "Plugins/Process/elf-core/ProcessElfCore.h" #include "Plugins/Process/gdb-remote/ProcessGDBRemote.h" @@ -259,6 +261,11 @@ SystemInitializerCommon::Initialize(); ScriptInterpreterNone::Initialize(); +#ifndef LLDB_DISABLE_PYTHON +OperatingSystemPython::Initialize(); +#endif +OperatingSystemGo::Initialize(); + #if !defined(LLDB_DISABLE_PYTHON) InitializeSWIG(); @@ -462,6 +469,11 @@ process_gdb_remote::ProcessGDBRemote::Terminate(); DynamicLoaderStatic::Terminate(); +#ifndef LLDB_DISABLE_PYTHON +OperatingSystemPython::Terminate(); +#endif +OperatingSystemGo::Terminate(); + // Now shutdown the common parts, in reverse order. SystemInitializerCommon::Terminate(); } Index: source/Initialization/SystemInitializerCommon.cpp === --- source/Initialization/SystemInitializerCommon.cpp +++ source/Initialization/SystemInitializerCommon.cpp @@ -25,8 +25,6 @@ #include "Plugins/ObjectContainer/Universal-Mach-O/ObjectContainerUniversalMachO.h" #include "Plugins/ObjectFile/ELF/ObjectFileELF.h" #include "Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h" -#include "Plugins/OperatingSystem/Python/OperatingSystemPython.h" -#include "Plugins/OperatingSystem/Go/OperatingSystemGo.h" #include "Plugins/Platform/Android/PlatformAndroid.h" #include "Plugins/Platform/FreeBSD/PlatformFreeBSD.h" #include "Plugins/Platform/Kalimba/PlatformKalimba.h" @@ -145,10 +143,6 @@ #if defined(_MSC_VER) ProcessWindowsLog::Initialize(); #endif -#ifndef LLDB_DISABLE_PYTHON -OperatingSystemPython::Initialize(); -#endif -OperatingSystemGo::Initialize(); } void @@ -189,11 +183,6 @@ ProcessWindowsLog::Terminate(); #endif -#ifndef LLDB_DISABLE_PYTHON -OperatingSystemPython::Terminate(); -#endif -OperatingSystemGo::Terminate(); - HostInfo::Terminate(); Log::Terminate(); } Index: source/API/SystemInitializerFull.cpp === --- source/API/SystemInitializerFull.cpp +++ source/API/SystemInitializerFull.cpp @@ -57,6 +57,8 @@ #include "Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h" #include "Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h" #include "Plugins/MemoryHistory/asan/MemoryHistoryASan.h" +#include "Plugins/OperatingSystem/Python/OperatingSystemPython.h" +#include "Plugins/OperatingSystem/Go/OperatingSystemGo.h" #include "Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h" #include "Plugins/Process/elf-core/ProcessElfCore.h" #include "Plugins/Process/gdb-remote/ProcessGDBRemote.h" @@ -259,6 +261,11 @@ SystemInitializerCommon::Initialize(); ScriptInterpreterNone::Initialize(); +#ifndef LLDB_DISABLE_PYTHON +OperatingSystemPython::
Re: [Lldb-commits] [PATCH] D18176: Fix thread/process ID reading from linux core files
zturner accepted this revision. zturner added a comment. This revision is now accepted and ready to land. Good to see we have a way to generate reasonably sized core files on other platforms as well. http://reviews.llvm.org/D18176 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18140: [test] Persist packets between expect_gdbremote_sequence invocations
tfiala accepted this revision. tfiala added a comment. This revision is now accepted and ready to land. LGTM, Pavel! http://reviews.llvm.org/D18140 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D18194: Abstract the debug info parser from the ASTContext
zturner created this revision.
zturner added a reviewer: clayborg.
zturner added a subscriber: lldb-commits.
ClangASTContext was assuming the presence of DWARF debug info, so it was baked
into the class that DWARFASTParserClang would be used. This won't be the case
with PDB, which will need a PDBASTParserClang. This will be used for PDB's
generated by MSVC (since it is ABI compatible with clang-cl) as well as (in the
future) PDBs generated directly by clang.
For now PDBASTParserClang is not implemented, this only breaks up the
DWARFASTParser class into an abstraction that is not dwarf dependent, and has
ClangASTContext deal only with this abstraction, while SymbolFileDWARF can deal
directly with the DWARFASTParser.
http://reviews.llvm.org/D18194
Files:
include/lldb/Symbol/ClangASTContext.h
include/lldb/Symbol/DebugInfoASTParser.h
include/lldb/Symbol/GoASTContext.h
include/lldb/Symbol/JavaASTContext.h
include/lldb/Symbol/SymbolFile.h
include/lldb/Symbol/TypeSystem.h
source/Plugins/SymbolFile/DWARF/DWARFASTParser.h
source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
source/Symbol/ClangASTContext.cpp
source/Symbol/GoASTContext.cpp
source/Symbol/JavaASTContext.cpp
Index: source/Symbol/JavaASTContext.cpp
===
--- source/Symbol/JavaASTContext.cpp
+++ source/Symbol/JavaASTContext.cpp
@@ -496,8 +496,8 @@
return m_pointer_byte_size;
}
-DWARFASTParser *
-JavaASTContext::GetDWARFParser()
+DebugInfoASTParser *
+JavaASTContext::GetDebugInfoASTParser()
{
if (!m_dwarf_ast_parser_ap)
m_dwarf_ast_parser_ap.reset(new DWARFASTParserJava(*this));
Index: source/Symbol/GoASTContext.cpp
===
--- source/Symbol/GoASTContext.cpp
+++ source/Symbol/GoASTContext.cpp
@@ -1639,8 +1639,8 @@
return (kind & GoType::KIND_DIRECT_IFACE) == GoType::KIND_DIRECT_IFACE;
}
-DWARFASTParser *
-GoASTContext::GetDWARFParser()
+DebugInfoASTParser *
+GoASTContext::GetDebugInfoASTParser()
{
if (!m_dwarf_ast_parser_ap)
m_dwarf_ast_parser_ap.reset(new DWARFASTParserGo(*this));
Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -9653,16 +9653,17 @@
}
}
-
-DWARFASTParser *
-ClangASTContext::GetDWARFParser ()
+DebugInfoASTParser *
+ClangASTContext::GetDebugInfoASTParser()
{
-if (!m_dwarf_ast_parser_ap)
-m_dwarf_ast_parser_ap.reset(new DWARFASTParserClang(*this));
-return m_dwarf_ast_parser_ap.get();
+if (!m_di_ast_parser_ap)
+{
+if (m_sym_file->GetSymbolFileFormat() == SymbolFileFormat::DWARF)
+m_di_ast_parser_ap.reset(new DWARFASTParserClang(*this));
+}
+return m_di_ast_parser_ap.get();
}
-
bool
ClangASTContext::LayoutRecordType(void *baton,
const clang::RecordDecl *record_decl,
@@ -9673,8 +9674,9 @@
llvm::DenseMap &vbase_offsets)
{
ClangASTContext *ast = (ClangASTContext *)baton;
-DWARFASTParserClang *dwarf_ast_parser = (DWARFASTParserClang *)ast->GetDWARFParser();
-return dwarf_ast_parser->LayoutRecordType(record_decl, bit_size, alignment, field_offsets, base_offsets, vbase_offsets);
+DebugInfoASTParser *di_ast_parser = ast->GetDebugInfoASTParser();
+return di_ast_parser->LayoutRecordType(record_decl, bit_size, alignment, field_offsets, base_offsets,
+ vbase_offsets);
}
//--
Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
@@ -55,6 +55,9 @@
void
InitializeObject() override;
+lldb_private::SymbolFileFormat
+GetSymbolFileFormat() const override;
+
//--
// Compile Unit function calls
//--
Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
@@ -118,6 +118,12 @@
m_session_up->setLoadAddress(obj_load_address);
}
+lldb_private::SymbolFileFormat
+SymbolFilePDB::GetSymbolFileFormat() const
+{
+return SymbolFileFormat::PDB;
+}
+
uint32_t
SymbolFilePDB::GetNumCompileUnits()
{
Index: source/Plugins/S
Re: [Lldb-commits] [PATCH] D18194: Abstract the debug info parser from the ASTContext
zturner abandoned this revision. zturner added a comment. Abandoning this for now, I ran into some difficulties when trying to implement the PDB version. Will have to resolve those first and then come back to this. http://reviews.llvm.org/D18194 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r263588 - Remove unnecessary includes.
Author: jingham Date: Tue Mar 15 16:11:02 2016 New Revision: 263588 URL: http://llvm.org/viewvc/llvm-project?rev=263588&view=rev Log: Remove unnecessary includes. Modified: lldb/trunk/source/Core/DataEncoder.cpp lldb/trunk/source/Core/DataExtractor.cpp lldb/trunk/source/Core/Disassembler.cpp lldb/trunk/source/Core/FileSpecList.cpp lldb/trunk/source/Core/SearchFilter.cpp lldb/trunk/source/Core/Section.cpp lldb/trunk/source/Host/common/Host.cpp Modified: lldb/trunk/source/Core/DataEncoder.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/DataEncoder.cpp?rev=263588&r1=263587&r2=263588&view=diff == --- lldb/trunk/source/Core/DataEncoder.cpp (original) +++ lldb/trunk/source/Core/DataEncoder.cpp Tue Mar 15 16:11:02 2016 @@ -13,7 +13,6 @@ // C++ Includes #include #include -#include // Other libraries and framework includes #include "llvm/Support/MathExtras.h" Modified: lldb/trunk/source/Core/DataExtractor.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/DataExtractor.cpp?rev=263588&r1=263587&r2=263588&view=diff == --- lldb/trunk/source/Core/DataExtractor.cpp (original) +++ lldb/trunk/source/Core/DataExtractor.cpp Tue Mar 15 16:11:02 2016 @@ -13,7 +13,6 @@ #include #include #include -#include #include #include Modified: lldb/trunk/source/Core/Disassembler.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Disassembler.cpp?rev=263588&r1=263587&r2=263588&view=diff == --- lldb/trunk/source/Core/Disassembler.cpp (original) +++ lldb/trunk/source/Core/Disassembler.cpp Tue Mar 15 16:11:02 2016 @@ -13,7 +13,6 @@ // C++ Includes #include #include -#include // Other libraries and framework includes // Project includes Modified: lldb/trunk/source/Core/FileSpecList.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/FileSpecList.cpp?rev=263588&r1=263587&r2=263588&view=diff == --- lldb/trunk/source/Core/FileSpecList.cpp (original) +++ lldb/trunk/source/Core/FileSpecList.cpp Tue Mar 15 16:11:02 2016 @@ -12,7 +12,6 @@ // C Includes // C++ Includes #include -#include // Other libraries and framework includes // Project includes Modified: lldb/trunk/source/Core/SearchFilter.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/SearchFilter.cpp?rev=263588&r1=263587&r2=263588&view=diff == --- lldb/trunk/source/Core/SearchFilter.cpp (original) +++ lldb/trunk/source/Core/SearchFilter.cpp Tue Mar 15 16:11:02 2016 @@ -9,7 +9,6 @@ // C Includes // C++ Includes -#include // Other libraries and framework includes // Project includes Modified: lldb/trunk/source/Core/Section.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Section.cpp?rev=263588&r1=263587&r2=263588&view=diff == --- lldb/trunk/source/Core/Section.cpp (original) +++ lldb/trunk/source/Core/Section.cpp Tue Mar 15 16:11:02 2016 @@ -14,8 +14,6 @@ #include "lldb/Target/Target.h" #include "lldb/Utility/ConvertEnum.h" -#include - using namespace lldb; using namespace lldb_private; Modified: lldb/trunk/source/Host/common/Host.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/common/Host.cpp?rev=263588&r1=263587&r2=263588&view=diff == --- lldb/trunk/source/Host/common/Host.cpp (original) +++ lldb/trunk/source/Host/common/Host.cpp Tue Mar 15 16:11:02 2016 @@ -39,8 +39,10 @@ #include #endif -// C++ includes -#include +// C++ Includes + +// Other libraries and framework includes +// Project includes #include "lldb/Host/FileSystem.h" #include "lldb/Host/Host.h" ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r263333 - Let's not convert from UINT32_MAX to the std::numeric_limits version.
Is the stdint version better somehow? I thought C++ numeric_limits were
actually preferred over the C macros.
On Mon, Mar 14, 2016 at 7:59 AM Adrian McCarthy via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> If we're favoring the macros over the functions, then
> perhaps update the #includes?
>
> On Fri, Mar 11, 2016 at 7:33 PM, Jim Ingham via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: jingham
>> Date: Fri Mar 11 21:33:36 2016
>> New Revision: 26
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=26&view=rev
>> Log:
>> Let's not convert from UINT32_MAX to the std::numeric_limits version.
>>
>> Modified:
>> lldb/trunk/source/Core/DataEncoder.cpp
>> lldb/trunk/source/Core/Disassembler.cpp
>> lldb/trunk/source/Core/FileSpecList.cpp
>> lldb/trunk/source/Core/SearchFilter.cpp
>>
>> Modified: lldb/trunk/source/Core/DataEncoder.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/DataEncoder.cpp?rev=26&r1=263332&r2=26&view=diff
>>
>> ==
>> --- lldb/trunk/source/Core/DataEncoder.cpp (original)
>> +++ lldb/trunk/source/Core/DataEncoder.cpp Fri Mar 11 21:33:36 2016
>> @@ -233,7 +233,7 @@ DataEncoder::PutU8 (uint32_t offset, uin
>> m_start[offset] = value;
>> return offset + 1;
>> }
>> -return std::numeric_limits::max();
>> +return UINT32_MAX;
>> }
>>
>> uint32_t
>> @@ -248,7 +248,7 @@ DataEncoder::PutU16 (uint32_t offset, ui
>>
>> return offset + sizeof (value);
>> }
>> -return std::numeric_limits::max();
>> +return UINT32_MAX;
>> }
>>
>> uint32_t
>> @@ -263,7 +263,7 @@ DataEncoder::PutU32 (uint32_t offset, ui
>>
>> return offset + sizeof (value);
>> }
>> -return std::numeric_limits::max();
>> +return UINT32_MAX;
>> }
>>
>> uint32_t
>> @@ -278,7 +278,7 @@ DataEncoder::PutU64 (uint32_t offset, ui
>>
>> return offset + sizeof (value);
>> }
>> -return std::numeric_limits::max();
>> +return UINT32_MAX;
>> }
>>
>> //--
>> @@ -304,7 +304,7 @@ DataEncoder::PutMaxU64 (uint32_t offset,
>> assert(!"GetMax64 unhandled case!");
>> break;
>> }
>> -return std::numeric_limits::max();
>> +return UINT32_MAX;
>> }
>>
>> uint32_t
>> @@ -318,7 +318,7 @@ DataEncoder::PutData (uint32_t offset, c
>> memcpy (m_start + offset, src, src_len);
>> return offset + src_len;
>> }
>> -return std::numeric_limits::max();
>> +return UINT32_MAX;
>> }
>>
>> uint32_t
>> @@ -332,5 +332,5 @@ DataEncoder::PutCString (uint32_t offset
>> {
>> if (cstr != nullptr)
>> return PutData (offset, cstr, strlen(cstr) + 1);
>> -return std::numeric_limits::max();
>> +return UINT32_MAX;
>> }
>>
>> Modified: lldb/trunk/source/Core/Disassembler.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Disassembler.cpp?rev=26&r1=263332&r2=26&view=diff
>>
>> ==
>> --- lldb/trunk/source/Core/Disassembler.cpp (original)
>> +++ lldb/trunk/source/Core/Disassembler.cpp Fri Mar 11 21:33:36 2016
>> @@ -1036,7 +1036,7 @@ InstructionList::GetIndexOfNextBranchIns
>> {
>> size_t num_instructions = m_instructions.size();
>>
>> -uint32_t next_branch = std::numeric_limits::max();
>> +uint32_t next_branch = UINT32_MAX;
>> size_t i;
>> for (i = start; i < num_instructions; i++)
>> {
>> @@ -1053,7 +1053,7 @@ InstructionList::GetIndexOfNextBranchIns
>> if (target.GetArchitecture().GetTriple().getArch() ==
>> llvm::Triple::hexagon)
>> {
>> // If we didn't find a branch, find the last packet start.
>> -if (next_branch == std::numeric_limits::max())
>> +if (next_branch == UINT32_MAX)
>> {
>> i = num_instructions - 1;
>> }
>> @@ -1086,7 +1086,7 @@ InstructionList::GetIndexOfNextBranchIns
>> }
>> }
>>
>> -if (next_branch == std::numeric_limits::max())
>> +if (next_branch == UINT32_MAX)
>> {
>> // We couldn't find the previous packet, so return start
>> next_branch = start;
>> @@ -1099,7 +1099,7 @@ uint32_t
>> InstructionList::GetIndexOfInstructionAtAddress (const Address &address)
>> {
>> size_t num_instructions = m_instructions.size();
>> -uint32_t index = std::numeric_limits::max();
>> +uint32_t index = UINT32_MAX;
>> for (size_t i = 0; i < num_instructions; i++)
>> {
>> if (m_instructions[i]->GetAddress() == address)
>> @@ -1152,7 +1152,7 @@ Disassembler::ParseInstructions (const E
>> m_arch.GetByteOrder(),
>> m_arch.GetAddressByteSize());
>> const bool data_from_file = load_addr ==
>> LLDB_INVALID_AD
Re: [Lldb-commits] [lldb] r263333 - Let's not convert from UINT32_MAX to the std::numeric_limits version.
It doesn't look like there is any advantage to the numeric_limits if you
already know the type you are getting the max or min of. The template would be
nice for doing more generic programming, but we're never doing anything fancier
than "What is the max of a uint32_t". It doesn't look like there is any
advantage to the numeric_limits if you already know the type you are getting
the max or min of.
In general we tend not to use raw UINT32_MAX and the like, but semantically
significant equivalents like LLDB_INVALID_THREAD_ID, etc. Some of the uses of
UINT32_MAX here should have been LLDB_INVALID_FILE_INDEX32, for instance,
though not all. At some point we should go clean up uses of *_MAX and use more
meaningful defines where appropriate. But I can't see that there is any value
to replacing the current _MAX usage with the much more verbose numeric_limits
invocations.
Jim
> On Mar 15, 2016, at 2:20 PM, Zachary Turner wrote:
>
> Is the stdint version better somehow? I thought C++ numeric_limits were
> actually preferred over the C macros.
>
> On Mon, Mar 14, 2016 at 7:59 AM Adrian McCarthy via lldb-commits
> wrote:
> If we're favoring the macros over the functions, then
> perhaps update the #includes?
>
> On Fri, Mar 11, 2016 at 7:33 PM, Jim Ingham via lldb-commits
> wrote:
> Author: jingham
> Date: Fri Mar 11 21:33:36 2016
> New Revision: 26
>
> URL: http://llvm.org/viewvc/llvm-project?rev=26&view=rev
> Log:
> Let's not convert from UINT32_MAX to the std::numeric_limits version.
>
> Modified:
> lldb/trunk/source/Core/DataEncoder.cpp
> lldb/trunk/source/Core/Disassembler.cpp
> lldb/trunk/source/Core/FileSpecList.cpp
> lldb/trunk/source/Core/SearchFilter.cpp
>
> Modified: lldb/trunk/source/Core/DataEncoder.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/DataEncoder.cpp?rev=26&r1=263332&r2=26&view=diff
> ==
> --- lldb/trunk/source/Core/DataEncoder.cpp (original)
> +++ lldb/trunk/source/Core/DataEncoder.cpp Fri Mar 11 21:33:36 2016
> @@ -233,7 +233,7 @@ DataEncoder::PutU8 (uint32_t offset, uin
> m_start[offset] = value;
> return offset + 1;
> }
> -return std::numeric_limits::max();
> +return UINT32_MAX;
> }
>
> uint32_t
> @@ -248,7 +248,7 @@ DataEncoder::PutU16 (uint32_t offset, ui
>
> return offset + sizeof (value);
> }
> -return std::numeric_limits::max();
> +return UINT32_MAX;
> }
>
> uint32_t
> @@ -263,7 +263,7 @@ DataEncoder::PutU32 (uint32_t offset, ui
>
> return offset + sizeof (value);
> }
> -return std::numeric_limits::max();
> +return UINT32_MAX;
> }
>
> uint32_t
> @@ -278,7 +278,7 @@ DataEncoder::PutU64 (uint32_t offset, ui
>
> return offset + sizeof (value);
> }
> -return std::numeric_limits::max();
> +return UINT32_MAX;
> }
>
> //--
> @@ -304,7 +304,7 @@ DataEncoder::PutMaxU64 (uint32_t offset,
> assert(!"GetMax64 unhandled case!");
> break;
> }
> -return std::numeric_limits::max();
> +return UINT32_MAX;
> }
>
> uint32_t
> @@ -318,7 +318,7 @@ DataEncoder::PutData (uint32_t offset, c
> memcpy (m_start + offset, src, src_len);
> return offset + src_len;
> }
> -return std::numeric_limits::max();
> +return UINT32_MAX;
> }
>
> uint32_t
> @@ -332,5 +332,5 @@ DataEncoder::PutCString (uint32_t offset
> {
> if (cstr != nullptr)
> return PutData (offset, cstr, strlen(cstr) + 1);
> -return std::numeric_limits::max();
> +return UINT32_MAX;
> }
>
> Modified: lldb/trunk/source/Core/Disassembler.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Disassembler.cpp?rev=26&r1=263332&r2=26&view=diff
> ==
> --- lldb/trunk/source/Core/Disassembler.cpp (original)
> +++ lldb/trunk/source/Core/Disassembler.cpp Fri Mar 11 21:33:36 2016
> @@ -1036,7 +1036,7 @@ InstructionList::GetIndexOfNextBranchIns
> {
> size_t num_instructions = m_instructions.size();
>
> -uint32_t next_branch = std::numeric_limits::max();
> +uint32_t next_branch = UINT32_MAX;
> size_t i;
> for (i = start; i < num_instructions; i++)
> {
> @@ -1053,7 +1053,7 @@ InstructionList::GetIndexOfNextBranchIns
> if (target.GetArchitecture().GetTriple().getArch() ==
> llvm::Triple::hexagon)
> {
> // If we didn't find a branch, find the last packet start.
> -if (next_branch == std::numeric_limits::max())
> +if (next_branch == UINT32_MAX)
> {
> i = num_instructions - 1;
> }
> @@ -1086,7 +1086,7 @@ InstructionList::GetIndexOfNextBranchIns
> }
> }
>
> -if (next_branch == std::numeric_limits::max())
> +
[Lldb-commits] [lldb] r263592 - Improve the 'type lookup' command such that it guesses to use the current's frame language as the one to start searching from.
Author: enrico
Date: Tue Mar 15 16:50:51 2016
New Revision: 263592
URL: http://llvm.org/viewvc/llvm-project?rev=263592&view=rev
Log:
Improve the 'type lookup' command such that it guesses to use the current's
frame language as the one to start searching from.
Modified:
lldb/trunk/include/lldb/Target/StackFrame.h
lldb/trunk/source/Commands/CommandObjectType.cpp
lldb/trunk/source/Target/StackFrame.cpp
Modified: lldb/trunk/include/lldb/Target/StackFrame.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/StackFrame.h?rev=263592&r1=263591&r2=263592&view=diff
==
--- lldb/trunk/include/lldb/Target/StackFrame.h (original)
+++ lldb/trunk/include/lldb/Target/StackFrame.h Tue Mar 15 16:50:51 2016
@@ -478,6 +478,11 @@ public:
lldb::LanguageType
GetLanguage ();
+// similar to GetLanguage(), but is allowed to take a potentially
incorrect guess
+// if exact information is not available
+lldb::LanguageType
+GuessLanguage ();
+
//--
// lldb::ExecutionContextScope pure virtual functions
//--
Modified: lldb/trunk/source/Commands/CommandObjectType.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectType.cpp?rev=263592&r1=263591&r2=263592&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectType.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectType.cpp Tue Mar 15 16:50:51 2016
@@ -11,6 +11,7 @@
// C Includes
// C++ Includes
+#include
#include
#include
@@ -3344,7 +3345,9 @@ public:
std::vector languages;
-if (m_command_options.m_language == eLanguageTypeUnknown)
+bool is_global_search = false;
+
+if ( (is_global_search = (m_command_options.m_language ==
eLanguageTypeUnknown)) )
{
// FIXME: hardcoding languages is not good
languages.push_back(Language::FindPlugin(eLanguageTypeObjC));
@@ -3355,6 +3358,27 @@ public:
languages.push_back(Language::FindPlugin(m_command_options.m_language));
}
+// This is not the most efficient way to do this, but we support very
few languages
+// so the cost of the sort is going to be dwarfed by the actual lookup
anyway
+if (StackFrame* frame = m_exe_ctx.GetFramePtr())
+{
+LanguageType lang = frame->GuessLanguage();
+if (lang != eLanguageTypeUnknown)
+{
+std::sort(languages.begin(),
+ languages.end(),
+ [lang] (Language* lang1,
+ Language* lang2) -> bool {
+ if (!lang1 || !lang2) return false;
+ LanguageType lt1 = lang1->GetLanguageType();
+ LanguageType lt2 = lang2->GetLanguageType();
+ if (lt1 == lang) return true; // make the
selected frame's language come first
+ if (lt2 == lang) return false; // make the
selected frame's language come first
+ return (lt1 < lt2); // normal comparison
otherwise
+ });
+}
+}
+
for (Language* language : languages)
{
if (!language)
@@ -3374,6 +3398,9 @@ public:
}
}
}
+// this is "type lookup SomeName" and we did find a match, so
get out
+if (any_found && is_global_search)
+break;
}
}
Modified: lldb/trunk/source/Target/StackFrame.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/StackFrame.cpp?rev=263592&r1=263591&r2=263592&view=diff
==
--- lldb/trunk/source/Target/StackFrame.cpp (original)
+++ lldb/trunk/source/Target/StackFrame.cpp Tue Mar 15 16:50:51 2016
@@ -12,10 +12,11 @@
// Other libraries and framework includes
// Project includes
#include "lldb/Target/StackFrame.h"
-#include "lldb/Core/Module.h"
#include "lldb/Core/Debugger.h"
#include "lldb/Core/Disassembler.h"
#include "lldb/Core/FormatEntity.h"
+#include "lldb/Core/Mangled.h"
+#include "lldb/Core/Module.h"
#include "lldb/Core/Value.h"
#include "lldb/Core/ValueObjectVariable.h"
#include "lldb/Core/ValueObjectConstResult.h"
@@ -1356,6 +1357,23 @@ StackFrame::GetLanguage ()
return lldb::eLanguageTypeUnknown;
}
+lldb::LanguageType
+StackFrame::GuessLanguage ()
+{
+LanguageType lang_type = GetLanguage();
+
+if (lang_type == eLanguageTypeUnknown)
+{
+Function *f = GetSym
Re: [Lldb-commits] [lldb] r263333 - Let's not convert from UINT32_MAX to the std::numeric_limits version.
I agree that they are pretty much equivalent, I guess the main advantage I
see is that you don't have to think about what type something is when
assigning it an "invalid" value. For example, LLDB_INVALID_THREAD_ID could
just as easily be std::numeric_limits::min(), and then you
don't have to worry about whether it's signed, or unsigned, or 32 bits, or
64-bits.
I guess put another way, if they're equivalent then we should prefer the
C++ ones if for no other reason than that it makes porting refactoring,
porting, and other similar tasks easier in the future (even if it seems
unlikely and the benefit is mostly theoretical).
Anyway, doesn't really matter, I just thought it strange to see C++ code
ported to C, as usually it happens the other way around.
On Tue, Mar 15, 2016 at 2:37 PM Jim Ingham wrote:
> It doesn't look like there is any advantage to the numeric_limits if you
> already know the type you are getting the max or min of. The template
> would be nice for doing more generic programming, but we're never doing
> anything fancier than "What is the max of a uint32_t". It doesn't look
> like there is any advantage to the numeric_limits if you already know the
> type you are getting the max or min of.
>
> In general we tend not to use raw UINT32_MAX and the like, but
> semantically significant equivalents like LLDB_INVALID_THREAD_ID, etc.
> Some of the uses of UINT32_MAX here should have been
> LLDB_INVALID_FILE_INDEX32, for instance, though not all. At some point we
> should go clean up uses of *_MAX and use more meaningful defines where
> appropriate. But I can't see that there is any value to replacing the
> current _MAX usage with the much more verbose numeric_limits invocations.
>
> Jim
>
>
> > On Mar 15, 2016, at 2:20 PM, Zachary Turner wrote:
> >
> > Is the stdint version better somehow? I thought C++ numeric_limits were
> actually preferred over the C macros.
> >
> > On Mon, Mar 14, 2016 at 7:59 AM Adrian McCarthy via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> > If we're favoring the macros over the functions,
> then perhaps update the #includes?
> >
> > On Fri, Mar 11, 2016 at 7:33 PM, Jim Ingham via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> > Author: jingham
> > Date: Fri Mar 11 21:33:36 2016
> > New Revision: 26
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=26&view=rev
> > Log:
> > Let's not convert from UINT32_MAX to the std::numeric_limits version.
> >
> > Modified:
> > lldb/trunk/source/Core/DataEncoder.cpp
> > lldb/trunk/source/Core/Disassembler.cpp
> > lldb/trunk/source/Core/FileSpecList.cpp
> > lldb/trunk/source/Core/SearchFilter.cpp
> >
> > Modified: lldb/trunk/source/Core/DataEncoder.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/DataEncoder.cpp?rev=26&r1=263332&r2=26&view=diff
> >
> ==
> > --- lldb/trunk/source/Core/DataEncoder.cpp (original)
> > +++ lldb/trunk/source/Core/DataEncoder.cpp Fri Mar 11 21:33:36 2016
> > @@ -233,7 +233,7 @@ DataEncoder::PutU8 (uint32_t offset, uin
> > m_start[offset] = value;
> > return offset + 1;
> > }
> > -return std::numeric_limits::max();
> > +return UINT32_MAX;
> > }
> >
> > uint32_t
> > @@ -248,7 +248,7 @@ DataEncoder::PutU16 (uint32_t offset, ui
> >
> > return offset + sizeof (value);
> > }
> > -return std::numeric_limits::max();
> > +return UINT32_MAX;
> > }
> >
> > uint32_t
> > @@ -263,7 +263,7 @@ DataEncoder::PutU32 (uint32_t offset, ui
> >
> > return offset + sizeof (value);
> > }
> > -return std::numeric_limits::max();
> > +return UINT32_MAX;
> > }
> >
> > uint32_t
> > @@ -278,7 +278,7 @@ DataEncoder::PutU64 (uint32_t offset, ui
> >
> > return offset + sizeof (value);
> > }
> > -return std::numeric_limits::max();
> > +return UINT32_MAX;
> > }
> >
> > //--
> > @@ -304,7 +304,7 @@ DataEncoder::PutMaxU64 (uint32_t offset,
> > assert(!"GetMax64 unhandled case!");
> > break;
> > }
> > -return std::numeric_limits::max();
> > +return UINT32_MAX;
> > }
> >
> > uint32_t
> > @@ -318,7 +318,7 @@ DataEncoder::PutData (uint32_t offset, c
> > memcpy (m_start + offset, src, src_len);
> > return offset + src_len;
> > }
> > -return std::numeric_limits::max();
> > +return UINT32_MAX;
> > }
> >
> > uint32_t
> > @@ -332,5 +332,5 @@ DataEncoder::PutCString (uint32_t offset
> > {
> > if (cstr != nullptr)
> > return PutData (offset, cstr, strlen(cstr) + 1);
> > -return std::numeric_limits::max();
> > +return UINT32_MAX;
> > }
> >
> > Modified: lldb/trunk/source/Core/Disassembler.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Disassembler.cpp?rev=26&r1=263332&r2=26&view=diff
> >
> =
[Lldb-commits] [lldb] r263593 - Don't crash if the TypeSP is empty.
Author: gclayton
Date: Tue Mar 15 16:58:28 2016
New Revision: 263593
URL: http://llvm.org/viewvc/llvm-project?rev=263593&view=rev
Log:
Don't crash if the TypeSP is empty.
Modified:
lldb/trunk/include/lldb/Symbol/Type.h
Modified: lldb/trunk/include/lldb/Symbol/Type.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/Type.h?rev=263593&r1=263592&r2=263593&view=diff
==
--- lldb/trunk/include/lldb/Symbol/Type.h (original)
+++ lldb/trunk/include/lldb/Symbol/Type.h Tue Mar 15 16:58:28 2016
@@ -428,7 +428,10 @@ public:
SetType (lldb::TypeSP type)
{
type_sp = type;
-compiler_type = type_sp->GetForwardCompilerType ();
+if (type_sp)
+compiler_type = type_sp->GetForwardCompilerType ();
+else
+compiler_type.Clear();
}
lldb::TypeSP
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r263333 - Let's not convert from UINT32_MAX to the std::numeric_limits version.
> On Mar 15, 2016, at 3:00 PM, Zachary Turner wrote: > > I agree that they are pretty much equivalent, I guess the main advantage I > see is that you don't have to think about what type something is when > assigning it an "invalid" value. For example, LLDB_INVALID_THREAD_ID could > just as easily be std::numeric_limits::min(), and then you don't > have to worry about whether it's signed, or unsigned, or 32 bits, or 64-bits. > I'd be fine with this at the place where LLDB_INVALID_THREAD_ID was defined if that somehow made things more better. But std::numeric_limits::min() is not very expressive of the fact that you're testing for an invalid thread ID, so I wouldn't want to use that as the test in ordinary code. I bet many of the uses of UINT32_MAX are places where we should have invented (or did invent but didn't use) a more significant name. Cleaning that up will not be made easier by replacing UINT32_MAX with the limits version. Jim > > I guess put another way, if they're equivalent then we should prefer the C++ > ones if for no other reason than that it makes porting refactoring, porting, > and other similar tasks easier in the future (even if it seems unlikely and > the benefit is mostly theoretical). > > Anyway, doesn't really matter, I just thought it strange to see C++ code > ported to C, as usually it happens the other way around. > > On Tue, Mar 15, 2016 at 2:37 PM Jim Ingham wrote: > It doesn't look like there is any advantage to the numeric_limits if you > already know the type you are getting the max or min of. The template would > be nice for doing more generic programming, but we're never doing anything > fancier than "What is the max of a uint32_t". It doesn't look like there is > any advantage to the numeric_limits if you already know the type you are > getting the max or min of. > > In general we tend not to use raw UINT32_MAX and the like, but semantically > significant equivalents like LLDB_INVALID_THREAD_ID, etc. Some of the uses > of UINT32_MAX here should have been LLDB_INVALID_FILE_INDEX32, for instance, > though not all. At some point we should go clean up uses of *_MAX and use > more meaningful defines where appropriate. But I can't see that there is any > value to replacing the current _MAX usage with the much more verbose > numeric_limits invocations. > > Jim > > > > On Mar 15, 2016, at 2:20 PM, Zachary Turner wrote: > > > > Is the stdint version better somehow? I thought C++ numeric_limits were > > actually preferred over the C macros. > > > > On Mon, Mar 14, 2016 at 7:59 AM Adrian McCarthy via lldb-commits > > wrote: > > If we're favoring the macros over the functions, then > > perhaps update the #includes? > > > > On Fri, Mar 11, 2016 at 7:33 PM, Jim Ingham via lldb-commits > > wrote: > > Author: jingham > > Date: Fri Mar 11 21:33:36 2016 > > New Revision: 26 > > > > URL: http://llvm.org/viewvc/llvm-project?rev=26&view=rev > > Log: > > Let's not convert from UINT32_MAX to the std::numeric_limits version. > > > > Modified: > > lldb/trunk/source/Core/DataEncoder.cpp > > lldb/trunk/source/Core/Disassembler.cpp > > lldb/trunk/source/Core/FileSpecList.cpp > > lldb/trunk/source/Core/SearchFilter.cpp > > > > Modified: lldb/trunk/source/Core/DataEncoder.cpp > > URL: > > http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/DataEncoder.cpp?rev=26&r1=263332&r2=26&view=diff > > == > > --- lldb/trunk/source/Core/DataEncoder.cpp (original) > > +++ lldb/trunk/source/Core/DataEncoder.cpp Fri Mar 11 21:33:36 2016 > > @@ -233,7 +233,7 @@ DataEncoder::PutU8 (uint32_t offset, uin > > m_start[offset] = value; > > return offset + 1; > > } > > -return std::numeric_limits::max(); > > +return UINT32_MAX; > > } > > > > uint32_t > > @@ -248,7 +248,7 @@ DataEncoder::PutU16 (uint32_t offset, ui > > > > return offset + sizeof (value); > > } > > -return std::numeric_limits::max(); > > +return UINT32_MAX; > > } > > > > uint32_t > > @@ -263,7 +263,7 @@ DataEncoder::PutU32 (uint32_t offset, ui > > > > return offset + sizeof (value); > > } > > -return std::numeric_limits::max(); > > +return UINT32_MAX; > > } > > > > uint32_t > > @@ -278,7 +278,7 @@ DataEncoder::PutU64 (uint32_t offset, ui > > > > return offset + sizeof (value); > > } > > -return std::numeric_limits::max(); > > +return UINT32_MAX; > > } > > > > //-- > > @@ -304,7 +304,7 @@ DataEncoder::PutMaxU64 (uint32_t offset, > > assert(!"GetMax64 unhandled case!"); > > break; > > } > > -return std::numeric_limits::max(); > > +return UINT32_MAX; > > } > > > > uint32_t > > @@ -318,7 +318,7 @@ DataEncoder::PutData (uint32_t offset, c > > memcpy (m_start + offset, src, src_len)
Re: [Lldb-commits] [PATCH] D18044: Fix a couple of cornercases in FileSpec + tests
This actually broke a couple of unit tests on Windows. Did you try running these tests on Windows? On Fri, Mar 11, 2016 at 12:49 AM Pavel Labath wrote: > This revision was automatically updated to reflect the committed changes. > Closed by commit rL263207: Fix a couple of cornercases in FileSpec + tests > (authored by labath). > > Changed prior to commit: > http://reviews.llvm.org/D18044?vs=50275&id=50396#toc > > Repository: > rL LLVM > > http://reviews.llvm.org/D18044 > > Files: > lldb/trunk/source/Host/common/FileSpec.cpp > lldb/trunk/unittests/Host/CMakeLists.txt > lldb/trunk/unittests/Host/FileSpecTest.cpp > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r263601 - Fix ClangASTContext::GetFunctionArgumentAtIndex() to not water down the type to the canonical type before handing the type out for the function type.
Author: gclayton
Date: Tue Mar 15 17:43:26 2016
New Revision: 263601
URL: http://llvm.org/viewvc/llvm-project?rev=263601&view=rev
Log:
Fix ClangASTContext::GetFunctionArgumentAtIndex() to not water down the type to
the canonical type before handing the type out for the function type.
Modified:
lldb/trunk/source/Symbol/ClangASTContext.cpp
Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=263601&r1=263600&r2=263601&view=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Tue Mar 15 17:43:26 2016
@@ -3185,7 +3185,7 @@ ClangASTContext::GetFunctionArgumentAtIn
{
if (type)
{
-clang::QualType qual_type (GetCanonicalQualType(type));
+clang::QualType qual_type (GetQualType(type));
const clang::FunctionProtoType* func =
llvm::dyn_cast(qual_type.getTypePtr());
if (func)
{
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r263602 - Only try to load the OS plug-in after a shared library load if we don't already have one.
Author: gclayton Date: Tue Mar 15 17:44:07 2016 New Revision: 263602 URL: http://llvm.org/viewvc/llvm-project?rev=263602&view=rev Log: Only try to load the OS plug-in after a shared library load if we don't already have one. Modified: lldb/trunk/source/Target/Process.cpp Modified: lldb/trunk/source/Target/Process.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Process.cpp?rev=263602&r1=263601&r2=263602&view=diff == --- lldb/trunk/source/Target/Process.cpp (original) +++ lldb/trunk/source/Target/Process.cpp Tue Mar 15 17:44:07 2016 @@ -6410,7 +6410,10 @@ Process::ModulesDidLoad (ModuleList &mod language_runtime_sp->ModulesDidLoad(module_list); } -LoadOperatingSystemPlugin(false); +// If we don't have an operating system plug-in, try to load one since +// loading shared libraries might cause a new one to try and load +if (!m_os_ap) +LoadOperatingSystemPlugin(false); } void ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r263603 - Make it so that the data formatter for NSError can see through a variable of type NSError**. Fixes rdar://25060684
Author: enrico
Date: Tue Mar 15 18:20:10 2016
New Revision: 263603
URL: http://llvm.org/viewvc/llvm-project?rev=263603&view=rev
Log:
Make it so that the data formatter for NSError can see through a variable of
type NSError**. Fixes rdar://25060684
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/main.m
lldb/trunk/source/Plugins/Language/ObjC/NSError.cpp
lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py?rev=263603&r1=263602&r2=263603&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
Tue Mar 15 18:20:10 2016
@@ -254,6 +254,9 @@ class ObjCDataFormatterTestCase(TestBase
self.expect('frame variable nserror',
substrs = ['domain: @"Foobar" - code: 12'])
+self.expect('frame variable nserrorptr',
+substrs = ['domain: @"Foobar" - code: 12'])
+
self.expect('frame variable nserror->_userInfo',
substrs = ['2 key/value pairs'])
@@ -268,10 +271,10 @@ class ObjCDataFormatterTestCase(TestBase
def nsexception_data_formatter_commands(self):
self.expect('frame variable except0 except1 except2 except3',
-substrs = ['(NSException *) except0 =
','name:@"TheGuyWhoHasNoName" reason:@"cuz it\'s funny"',
-'(NSException *) except1 = ','name:@"TheGuyWhoHasNoName~1"
reason:@"cuz it\'s funny"',
-'(NSException *) except2 = ','name:@"TheGuyWhoHasNoName`2"
reason:@"cuz it\'s funny"',
-'(NSException *) except3 = ','name:@"TheGuyWhoHasNoName/3"
reason:@"cuz it\'s funny"'])
+substrs = ['(NSException *) except0 = ','name:
@"TheGuyWhoHasNoName" - reason: @"cuz it\'s funny"',
+'(NSException *) except1 = ','name:
@"TheGuyWhoHasNoName~1" - reason: @"cuz it\'s funny"',
+'(NSException *) except2 = ','name:
@"TheGuyWhoHasNoName`2" - reason: @"cuz it\'s funny"',
+'(NSException *) except3 = ','name:
@"TheGuyWhoHasNoName/3" - reason: @"cuz it\'s funny"'])
def nsmisc_data_formatter_commands(self):
self.expect('frame variable localhost',
@@ -402,7 +405,6 @@ class ObjCDataFormatterTestCase(TestBase
'(Rect *) rect_ptr = (t=4, l=8, b=4, r=7)',
'(Point) point = (v=7, h=12)',
'(Point *) point_ptr = (v=7, h=12)',
- 'name:@"TheGuyWhoHasNoName" reason:@"cuz it\'s funny"',
'1985',
'foo_selector_impl'];
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/main.m
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/main.m?rev=263603&r1=263602&r2=263603&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/main.m
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/main.m
Tue Mar 15 18:20:10 2016
@@ -485,6 +485,7 @@ int main (int argc, const char * argv[])
NSDictionary *error_userInfo = @{@"a": @1, @"b" : @2};
NSError *nserror = [[NSError alloc] initWithDomain:@"Foobar"
code:12 userInfo:error_userInfo];
+ NSError **nserrorptr = &nserror;
NSBundle* bundle_string = [[NSBundle alloc]
initWithPath:@"/System/Library/Frameworks/Accelerate.framework"];
NSBundle* bundle_url = [[NSBundle alloc] initWithURL:[[NSURL alloc]
initWithString:@"file://localhost/System/Library/Frameworks/Cocoa.framework"]];
Modified: lldb/trunk/source/Plugins/Language/ObjC/NSError.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/ObjC/NSError.cpp?rev=263603&r1=263602&r2=263603&view=diff
==
--- lldb/trunk/source/Plugins/Language/ObjC/NSError.cpp (original)
+++ lldb/trunk/source/Plugins/Language/ObjC/NSError.cpp Tue Mar 15 18:20:10 2016
@@ -34,27 +34,49 @@ using namespace lldb;
using namespace lldb_private;
using namespace lldb_private::formatters;
-bool
-lldb_private::formatters::NS
[Lldb-commits] [lldb] r263604 - On some platforms, the compiler is allowed to assume that BOOL == bool. On others, BOOL == signed char.
Author: enrico
Date: Tue Mar 15 18:38:04 2016
New Revision: 263604
URL: http://llvm.org/viewvc/llvm-project?rev=263604&view=rev
Log:
On some platforms, the compiler is allowed to assume that BOOL == bool. On
others, BOOL == signed char.
This can cause differences in which bit patterns end up meaning YES or NO. In
general, however, 0 == NO and 1 == YES.
To keep it simple, LLDB will now show "YES" and "NO" only for 1 and 0
respectively, and format other values as the plain numeric value instead.
Fixes rdar://24809994
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/boolreference/TestFormattersBoolRefPtr.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/boolreference/main.mm
lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/boolreference/TestFormattersBoolRefPtr.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/boolreference/TestFormattersBoolRefPtr.py?rev=263604&r1=263603&r2=263604&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/boolreference/TestFormattersBoolRefPtr.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/boolreference/TestFormattersBoolRefPtr.py
Tue Mar 15 18:38:04 2016
@@ -57,6 +57,8 @@ class DataFormatterBoolRefPtr(TestBase):
substrs = ['YES'])
self.expect('frame variable no_ref',
substrs = ['NO'])
+self.expect('frame variable unset_ref',
+substrs = ['12'])
# Now check that we use the right summary for BOOL*
@@ -64,6 +66,8 @@ class DataFormatterBoolRefPtr(TestBase):
substrs = ['YES'])
self.expect('frame variable no_ptr',
substrs = ['NO'])
+self.expect('frame variable unset_ptr',
+substrs = ['12'])
# Now check that we use the right summary for BOOL
@@ -71,3 +75,5 @@ class DataFormatterBoolRefPtr(TestBase):
substrs = ['YES'])
self.expect('frame variable no',
substrs = ['NO'])
+self.expect('frame variable unset',
+substrs = ['12'])
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/boolreference/main.mm
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/boolreference/main.mm?rev=263604&r1=263603&r2=263604&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/boolreference/main.mm
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/boolreference/main.mm
Tue Mar 15 18:38:04 2016
@@ -11,17 +11,19 @@
int main (int argc, const char * argv[])
{
-
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
BOOL yes = YES;
BOOL no = NO;
+BOOL unset = 12;
BOOL &yes_ref = yes;
BOOL &no_ref = no;
+ BOOL &unset_ref = unset;
BOOL* yes_ptr = &yes;
BOOL* no_ptr = &no;
+ BOOL* unset_ptr = &unset;
[pool drain];// Set break point at this line.
return 0;
Modified: lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp?rev=263604&r1=263603&r2=263604&view=diff
==
--- lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp (original)
+++ lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp Tue Mar 15 18:38:04 2016
@@ -870,13 +870,19 @@ lldb_private::formatters::ObjCBOOLSummar
if (!real_guy_sp)
return false;
}
-uint64_t value = real_guy_sp->GetValueAsUnsigned(0);
-if (value == 0)
+uint8_t value = (real_guy_sp->GetValueAsUnsigned(0) & 0xFF);
+switch (value)
{
-stream.Printf("NO");
-return true;
+case 0:
+stream.Printf("NO");
+break;
+case 1:
+stream.Printf("YES");
+break;
+default:
+stream.Printf("%u",value);
+break;
}
-stream.Printf("YES");
return true;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] Improving the documentation
Great! Attached is the update. On Thu, Mar 10, 2016 at 6:57 PM, Jim Ingham wrote: > Few more comments... > > +/// If an address comes from an existing module, then it will be resolved > +/// into an offset from its containing section in that module. That way > it > +/// can refer to the same logical location as the module that holds it > even > > Probably my error, but "location as the module" -> "location in the module" > > You use the terms "file virtual address" and "load virtual address". I > don't know what virtual means in that context. > > > +//-- > +/// Tries to resolve the address within the target. If this fails, > > "target" -> "target's modules"? That makes it clearer what's going on. > > +/// assumes the address is absolute, e.g., on the stack or heap. The > +/// object becomes valid. > +/// > +/// @param[in] load_addr > +/// A new offset value for this object. > > This isn't right, it isn't the new offset value, for instance if this is a > load address from a loaded module, > the SBAddress will be the containing section + offset, and load_addr != > SBAddress.GetOffset(). This is just the > load address that will be resolved. > > +/// > +/// @param[in] target > +/// The target within which the offset is valid. > > "The target within which the load address will be resolved" is better. > This will always return a valid SBAddress, it > just might or might not be a section-relative one. > > +//-- > void > SetLoadAddress (lldb::addr_t load_addr, > lldb::SBTarget &target); > > And "The target within which the offset is valid." -> "The target within > which the load address will be resolved"? > > > +//-- > +/// Set the offset for this address, relative to the current section, > +/// if any. > +/// > +/// @param[in] offset > +/// A new offset value for this object. > +//-- > +// FIXME: Should this be SetOffsetAddress? > bool > OffsetAddress (addr_t offset); > > This call actually slides the SBAddress, so new_offset = old_offset + > offset > > > > On Mar 10, 2016, at 10:46 AM, John Lindal > wrote: > > > > Thanks for your patience and feedback! Attached is the updated file. > > > > John > > > > On Wed, Mar 9, 2016 at 3:10 PM, Jim Ingham wrote: > > The relation between section offsets and files is stronger than you are > stating here. You say: > > > > +/// Represents an address. An address may refer to code or data from an > > +/// existing module, or it may refer to something on the stack or heap. > > +/// > > > > That part is good, but you should use that in the next paragraph, so > instead of: > > > > +/// If an address comes from a file on disk that has section relative > > +/// addresses, then it has a virtual address that is relative to a > unique > > +/// section in the object file. Sections get resolved at runtime by > > +/// DynamicLoader plug-ins as images (executables and shared libraries) > get > > +/// loaded/unloaded. If a section is loaded, then the load address can > be > > +/// resolved. > > > > Something like: > > > > If an address comes from an existing module, then it will be resolved > into an offset > > from its containing section in that module. That way it can refer to > the same logical > > location as the module that holds it is unloaded and loaded at different > addresses. > > Module based SBAddresses are not bound to a particular target or > process, but you > > can ask the SBAddress where/if it has been loaded in a particular target. > > > > I don't think you need to mention the Dynamic loader plugin here, it > isn't essential to know who tracks the > > loads to understand what these do. Also, you use "resolve" in the rest > of the docs to mean "resolve to > > section/offset in a Module. So using it for loading libraries here is > confusing. Better to define it > > here as you are going to use it. > > > > This bit doesn't seem right to me: > > > > -// The following queries can lookup symbol information for a given > address. > > -// An address might refer to code or data from an existing module, > or it > > -// might refer to something on the stack or heap. The following > functions > > -// will only return valid values if the address has been resolved > to a code > > -// or data address using "void SBAddress::SetLoadAddress(...)" or > > -// "lldb::SBAddress SBTarget::ResolveLoadAddress (...)". > > +//-- > > +/// Lookup symbol information for this address. This function will > only > > +/// return a valid object if the address has been resolved to a > code or > > +/// data add
Re: [Lldb-commits] Improving the documentation
The only other suggestion I have is that the first time we refer to a module in this file we should say "(see SBModule)" or something like that to make it clear what we mean by a module. Other than that this looks good to me. Jim > On Mar 15, 2016, at 5:05 PM, John Lindal wrote: > > Great! Attached is the update. > > On Thu, Mar 10, 2016 at 6:57 PM, Jim Ingham wrote: > Few more comments... > > +/// If an address comes from an existing module, then it will be resolved > +/// into an offset from its containing section in that module. That way it > +/// can refer to the same logical location as the module that holds it even > > Probably my error, but "location as the module" -> "location in the module" > > You use the terms "file virtual address" and "load virtual address". I don't > know what virtual means in that context. > > > +//-- > +/// Tries to resolve the address within the target. If this fails, > > "target" -> "target's modules"? That makes it clearer what's going on. > > +/// assumes the address is absolute, e.g., on the stack or heap. The > +/// object becomes valid. > +/// > +/// @param[in] load_addr > +/// A new offset value for this object. > > This isn't right, it isn't the new offset value, for instance if this is a > load address from a loaded module, > the SBAddress will be the containing section + offset, and load_addr != > SBAddress.GetOffset(). This is just the > load address that will be resolved. > > +/// > +/// @param[in] target > +/// The target within which the offset is valid. > > "The target within which the load address will be resolved" is better. This > will always return a valid SBAddress, it > just might or might not be a section-relative one. > > +//-- > void > SetLoadAddress (lldb::addr_t load_addr, > lldb::SBTarget &target); > > And "The target within which the offset is valid." -> "The target within > which the load address will be resolved"? > > > +//-- > +/// Set the offset for this address, relative to the current section, > +/// if any. > +/// > +/// @param[in] offset > +/// A new offset value for this object. > +//-- > +// FIXME: Should this be SetOffsetAddress? > bool > OffsetAddress (addr_t offset); > > This call actually slides the SBAddress, so new_offset = old_offset + offset > > > > On Mar 10, 2016, at 10:46 AM, John Lindal > > wrote: > > > > Thanks for your patience and feedback! Attached is the updated file. > > > > John > > > > On Wed, Mar 9, 2016 at 3:10 PM, Jim Ingham wrote: > > The relation between section offsets and files is stronger than you are > > stating here. You say: > > > > +/// Represents an address. An address may refer to code or data from an > > +/// existing module, or it may refer to something on the stack or heap. > > +/// > > > > That part is good, but you should use that in the next paragraph, so > > instead of: > > > > +/// If an address comes from a file on disk that has section relative > > +/// addresses, then it has a virtual address that is relative to a unique > > +/// section in the object file. Sections get resolved at runtime by > > +/// DynamicLoader plug-ins as images (executables and shared libraries) get > > +/// loaded/unloaded. If a section is loaded, then the load address can be > > +/// resolved. > > > > Something like: > > > > If an address comes from an existing module, then it will be resolved into > > an offset > > from its containing section in that module. That way it can refer to the > > same logical > > location as the module that holds it is unloaded and loaded at different > > addresses. > > Module based SBAddresses are not bound to a particular target or process, > > but you > > can ask the SBAddress where/if it has been loaded in a particular target. > > > > I don't think you need to mention the Dynamic loader plugin here, it isn't > > essential to know who tracks the > > loads to understand what these do. Also, you use "resolve" in the rest of > > the docs to mean "resolve to > > section/offset in a Module. So using it for loading libraries here is > > confusing. Better to define it > > here as you are going to use it. > > > > This bit doesn't seem right to me: > > > > -// The following queries can lookup symbol information for a given > > address. > > -// An address might refer to code or data from an existing module, or > > it > > -// might refer to something on the stack or heap. The following > > functions > > -// will only return valid values if the address has been resolved to a > > code > > -// or data address using "void SBAddress::SetLoadA
Re: [Lldb-commits] [PATCH] D17022: [LLDB][MIPS] Provide CPU string to compiler for appropriate code generation for MIPS
bhushan closed this revision. bhushan added a comment. Closed by commit http://reviews.llvm.org/rL261206 Repository: rL LLVM http://reviews.llvm.org/D17022 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
