[Lldb-commits] [PATCH] D32137: [Utility] Placate another GCC warning
labath added a comment. Thanks for digging into this, I've learned something new today. Fixing this with a cast seems reasonable then. https://reviews.llvm.org/D32137 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32149: Correct handling NetBSD core(5) files with threads
labath added a comment. A test would infinitely times more valuable then a demo script. What is the tiniest core file you can produce on NetBSD? (on linux we've gotten them down to about 20K) Then we could check that in and write a test for it... Repository: rL LLVM https://reviews.llvm.org/D32149 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D29581: Initial implementation of SB APIs for Tracing support.
ravitheja updated this revision to Diff 95930.
ravitheja added a comment.
New diff with requested changes.
https://reviews.llvm.org/D29581
Files:
include/lldb/API/LLDB.h
include/lldb/API/SBDefines.h
include/lldb/API/SBError.h
include/lldb/API/SBProcess.h
include/lldb/API/SBStructuredData.h
include/lldb/API/SBTrace.h
include/lldb/API/SBTraceOptions.h
include/lldb/Core/StructuredDataImpl.h
include/lldb/Core/TraceOptions.h
include/lldb/Target/Process.h
include/lldb/lldb-enumerations.h
include/lldb/lldb-forward.h
scripts/interface/SBProcess.i
scripts/interface/SBStructuredData.i
scripts/interface/SBTrace.i
scripts/interface/SBTraceOptions.i
scripts/lldb.swig
source/API/CMakeLists.txt
source/API/SBProcess.cpp
source/API/SBStructuredData.cpp
source/API/SBTrace.cpp
source/API/SBTraceOptions.cpp
Index: source/API/SBTraceOptions.cpp
===
--- /dev/null
+++ source/API/SBTraceOptions.cpp
@@ -0,0 +1,94 @@
+//===-- SBTraceOptions.cpp --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "lldb/API/SBTraceOptions.h"
+#include "lldb/API/SBError.h"
+#include "lldb/API/SBStructuredData.h"
+#include "lldb/Core/Log.h"
+#include "lldb/Core/StructuredDataImpl.h"
+#include "lldb/Core/TraceOptions.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBTraceOptions::SBTraceOptions() {
+ m_traceoptions_sp.reset(new TraceOptions());
+}
+
+lldb::TraceType SBTraceOptions::getType() const {
+ if (m_traceoptions_sp)
+return m_traceoptions_sp->getType();
+ return lldb::TraceType::eTraceTypeNone;
+}
+
+uint64_t SBTraceOptions::getTraceBufferSize() const {
+ if (m_traceoptions_sp)
+return m_traceoptions_sp->getTraceBufferSize();
+ return 0;
+}
+
+lldb::SBStructuredData SBTraceOptions::getTraceParams(lldb::SBError &error) {
+ error.Clear();
+ const lldb_private::StructuredData::DictionarySP dict_obj =
+ m_traceoptions_sp->getTraceParams();
+ lldb::SBStructuredData structData;
+ if (dict_obj && structData.m_impl_up)
+structData.m_impl_up->SetObjectSP(dict_obj->shared_from_this());
+ else
+error.SetErrorString("Empty trace params");
+ return structData;
+}
+
+uint64_t SBTraceOptions::getMetaDataBufferSize() const {
+ if (m_traceoptions_sp)
+return m_traceoptions_sp->getTraceBufferSize();
+ return 0;
+}
+
+void SBTraceOptions::setTraceParams(lldb::SBStructuredData ¶ms) {
+ if (m_traceoptions_sp && params.m_impl_up) {
+StructuredData::ObjectSP obj_sp = params.m_impl_up->GetObjectSP();
+if (obj_sp && obj_sp->GetAsDictionary() != nullptr)
+ m_traceoptions_sp->setTraceParams(
+ std::static_pointer_cast(obj_sp));
+ }
+ return;
+}
+
+void SBTraceOptions::setType(lldb::TraceType type) {
+ if (m_traceoptions_sp)
+m_traceoptions_sp->setType(type);
+}
+
+void SBTraceOptions::setTraceBufferSize(uint64_t size) {
+ if (m_traceoptions_sp)
+m_traceoptions_sp->setTraceBufferSize(size);
+}
+
+void SBTraceOptions::setMetaDataBufferSize(uint64_t size) {
+ if (m_traceoptions_sp)
+m_traceoptions_sp->setMetaDataBufferSize(size);
+}
+
+bool SBTraceOptions::IsValid() {
+ if (m_traceoptions_sp)
+return true;
+ return false;
+}
+
+void SBTraceOptions::setThreadID(lldb::tid_t thread_id) {
+ if (m_traceoptions_sp)
+m_traceoptions_sp->setThreadID(thread_id);
+}
+
+lldb::tid_t SBTraceOptions::getThreadID() {
+ if (m_traceoptions_sp)
+return m_traceoptions_sp->getThreadID();
+ return LLDB_INVALID_THREAD_ID;
+}
Index: source/API/SBTrace.cpp
===
--- /dev/null
+++ source/API/SBTrace.cpp
@@ -0,0 +1,109 @@
+//===-- SBTrace.cpp -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "lldb/Core/Log.h"
+#include "lldb/Target/Process.h"
+
+#include "lldb/API/SBTrace.h"
+#include "lldb/API/SBTraceOptions.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+class TraceImpl {
+public:
+ lldb::user_id_t uid;
+};
+
+lldb::ProcessSP SBTrace::GetSP() const { return m_opaque_wp.lock(); }
+
+size_t SBTrace::GetTraceData(SBError &error, void *buf, size_t size,
+ size_t offset, lldb::tid_t thread_id) {
+ size_t bytes_read = 0;
+ ProcessSP process_sp(GetSP());
+ Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
+ error.Clear();
+
+ if (!process_sp) {
+error.SetErrorString("invalid process");
+ } else {
+
[Lldb-commits] [PATCH] D29581: Initial implementation of SB APIs for Tracing support.
ravitheja marked 7 inline comments as done. ravitheja added inline comments. Comment at: include/lldb/API/SBProcess.h:251 + /// supported. To obtain the actual used trace options please + /// use the GetTraceConfig API. For the custom parameters, only + /// the parameters recognized by the target would be used and clayborg wrote: > Is GetTraceConfig an internal API? If so, lets not mention it here. You > general comments should suffice. No, its not an internal API, so just to throw some light to it, Processor trace integration for Linux does not support all buffer sizes so we are rounding the buffer sizes to the nearest supported buffer size and through GetTraceConfig we plan to communicate the actual trace buffer size being. https://reviews.llvm.org/D29581 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32149: Correct handling NetBSD core(5) files with threads
krytarowski added a comment.
In https://reviews.llvm.org/D32149#731887, @labath wrote:
> A test would infinitely times more valuable then a demo script. What is the
> tiniest core file you can produce on NetBSD? (on linux we've gotten them down
> to about 20K) Then we could check that in and write a test for it...
This is something I wanted to bring to the dev mailing list.
I wanted to prepare at least three tests, if possible four:
- one thread (if possible two variations: signal to one particular thread +
signal to all threads)
- multiple threads (signal to one particular thread + signal to all threads)
And this in combination of all supported targets (x86_64, i386, etc).
Emitting SIGABRT for such program gives core of size 97kilobytes:
int main(){for(;;);}
I will write assembly programs for the above cases, without libc.
Repository:
rL LLVM
https://reviews.llvm.org/D32149
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32149: Correct handling NetBSD core(5) files with threads
kettenis added a comment.
Generally looks reasonable to me. A few comments inline.
Comment at: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:1374
+else if ((note.n_name == LLDB_NT_OWNER_NETBSDCORE) &&
+ (note.n_type == LLDB_NT_NETBSD_NT_PROCINFO)) {
// Set the elf OS version to NetBSD. Also clear the vendor.
By making this change you risk losing recognition of "normal" NetBSD ELF files,
i.e. executables and shared libraries.
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:563
+
+/// Generic (Linux, ...) specific Thread context from PT_NOTE segment
+/// 1) A Thread Context in a core file usually described by 3 NOTE entries.
A bit strange to call something both generic and specific...
I think some of these note types originated on SVR4/Solaris, but I'm not sure
how much Linux deviated from that design through the years.
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:815
+return Error("Error parsing NetBSD core(5) notes: Cannot convert "
+ "LWP ID to integer");
+} else if (note.n_type == NETBSD::AMD64::NT_FPREGS) {
Wouldn't it make sense to move the parsing of the LWP ID before the switch.
Otherwise you'll have to duplicate the code for every NetBSD architecture
you'll add.
Repository:
rL LLVM
https://reviews.llvm.org/D32149
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r300833 - Add libc++ category the three more tests
Author: labath
Date: Thu Apr 20 06:27:58 2017
New Revision: 300833
URL: http://llvm.org/viewvc/llvm-project?rev=300833&view=rev
Log:
Add libc++ category the three more tests
I thought my previous commit got the last ones but somehow I missed
these. This also resurrects TestDataFormatterLibcxxSet, which got
commented out in r263859 as a part of some seemingly unrelated change.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py?rev=300833&r1=300832&r2=300833&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py
Thu Apr 20 06:27:58 2017
@@ -23,8 +23,7 @@ class LibCxxAtomicTestCase(TestBase):
var.SetPreferSyntheticValue(True)
return var
-@skipIf(compiler="gcc")
-@skipIfWindows # libc++ not ported to Windows yet
+@add_test_categories(["libc++"])
def test(self):
"""Test that std::atomic as defined by libc++ is correctly printed by
LLDB"""
self.build()
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py?rev=300833&r1=300832&r2=300833&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
Thu Apr 20 06:27:58 2017
@@ -30,8 +30,7 @@ class LibcxxListDataFormatterTestCase(Te
self.line4 = line_number('main.cpp',
'// Set fourth break point at this line.')
-@skipIf(compiler="gcc")
-@skipIfWindows # libc++ not ported to Windows yet
+@add_test_categories(["libc++"])
def test_with_run_command(self):
"""Test that that file and class static variables display correctly."""
self.build()
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py?rev=300833&r1=300832&r2=300833&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py
Thu Apr 20 06:27:58 2017
@@ -17,55 +17,112 @@ class LibcxxSetDataFormatterTestCase(Tes
mydir = TestBase.compute_mydir(__file__)
-@skipIf(compiler="gcc")
-@skipIfWindows # libc++ not ported to Windows yet
+def setUp(self):
+TestBase.setUp(self)
+ns = 'ndk' if lldbplatformutil.target_is_android() else ''
+self.namespace = 'std::__' + ns + '1'
+
+def getVariableType(self, name):
+var = self.frame().FindVariable(name)
+self.assertTrue(var.IsValid())
+return var.GetType().GetCanonicalType().GetName()
+
+@add_test_categories(["libc++"])
def test_with_run_command(self):
"""Test that that file and class static variables display correctly."""
self.build()
self.runCmd("file a.out", CURRENT_EXECUTABLE_SET)
-#bkpt =
self.target().FindBreakpointByID(lldbutil.run_break_set_by_source_regexp (self,
"Set break point at this line."))
+bkpt = self.target().FindBreakpointByID(
+lldbutil.run_break_set_by_source_regexp(self, "Set break point at
this line."))
self.runCmd("run", RUN_SUCCEEDED)
-#lldbuti
[Lldb-commits] [lldb] r300834 - Make TestStaticVariables XFAIL more specific
Author: labath Date: Thu Apr 20 06:28:07 2017 New Revision: 300834 URL: http://llvm.org/viewvc/llvm-project?rev=300834&view=rev Log: Make TestStaticVariables XFAIL more specific The test fails because an older clang did not emit the required debug info (I am not sure when this got added, but clang-3.7 certainly did not work yet). The actual platform has nothing to do with this. Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py?rev=300834&r1=300833&r2=300834&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py Thu Apr 20 06:28:07 2017 @@ -60,10 +60,9 @@ class StaticVariableTestCase(TestBase): compiler=["gcc"], bugnumber="Compiler emits incomplete debug info") @expectedFailureAll( -oslist=['linux']) -@expectedFailureAll( -oslist=['freebsd'], -bugnumber='llvm.org/pr20550 failing on FreeBSD-11') +compiler=["clang"], +compiler_version=["<", "3.8"], +bugnumber='llvm.org/pr20550') @add_test_categories(['pyapi']) def test_with_python_api(self): """Test Python APIs on file and class static variables.""" @@ -102,11 +101,11 @@ class StaticVariableTestCase(TestBase): if name == 'g_points': self.assertTrue( val.GetValueType() == lldb.eValueTypeVariableStatic) -self.assertTrue(val.GetNumChildren() == 2) +self.assertEqual(val.GetNumChildren(), 2) elif name == 'A::g_points': self.assertTrue( val.GetValueType() == lldb.eValueTypeVariableGlobal) -self.assertTrue(val.GetNumChildren() == 2) +self.assertEqual(val.GetNumChildren(), 2) child1 = val.GetChildAtIndex(1) self.DebugSBValue(child1) child1_x = child1.GetChildAtIndex(0) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32149: Correct handling NetBSD core(5) files with threads
kettenis added a comment. In https://reviews.llvm.org/D32149#731887, @labath wrote: > A test would infinitely times more valuable then a demo script. What is the > tiniest core file you can produce on NetBSD? (on linux we've gotten them down > to about 20K) Then we could check that in and write a test for it... The smalles core dumps I managed to create for OpenBSD so far are a bit over 4M. Repository: rL LLVM https://reviews.llvm.org/D32149 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32149: Correct handling NetBSD core(5) files with threads
krytarowski added inline comments.
Comment at: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:1374
+else if ((note.n_name == LLDB_NT_OWNER_NETBSDCORE) &&
+ (note.n_type == LLDB_NT_NETBSD_NT_PROCINFO)) {
// Set the elf OS version to NetBSD. Also clear the vendor.
kettenis wrote:
> By making this change you risk losing recognition of "normal" NetBSD ELF
> files, i.e. executables and shared libraries.
Hmm, do you mean these notes:
```
$ readelf -n /bin/cat
Displaying notes found at file offset 0x0214 with length 0x0018:
Owner Data size Description
NetBSD0x0004 IDENT 799005900 (7.99.59)
Displaying notes found at file offset 0x022c with length 0x0014:
Owner Data size Description
NetBSD0x0004 PaX <>
```
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:563
+
+/// Generic (Linux, ...) specific Thread context from PT_NOTE segment
+/// 1) A Thread Context in a core file usually described by 3 NOTE entries.
kettenis wrote:
> A bit strange to call something both generic and specific...
>
> I think some of these note types originated on SVR4/Solaris, but I'm not sure
> how much Linux deviated from that design through the years.
Can we call it: Type1 core (as of now: NetBSD) and Type2 core (Linux, Android,
FreeBSD, OpenBSD)?
I don't care which would be 1 and which 2.
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:815
+return Error("Error parsing NetBSD core(5) notes: Cannot convert "
+ "LWP ID to integer");
+} else if (note.n_type == NETBSD::AMD64::NT_FPREGS) {
kettenis wrote:
> Wouldn't it make sense to move the parsing of the LWP ID before the switch.
> Otherwise you'll have to duplicate the code for every NetBSD architecture
> you'll add.
Sounds good.
Repository:
rL LLVM
https://reviews.llvm.org/D32149
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32149: Correct handling NetBSD core(5) files with threads
kettenis added inline comments.
Comment at: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:1374
+else if ((note.n_name == LLDB_NT_OWNER_NETBSDCORE) &&
+ (note.n_type == LLDB_NT_NETBSD_NT_PROCINFO)) {
// Set the elf OS version to NetBSD. Also clear the vendor.
krytarowski wrote:
> kettenis wrote:
> > By making this change you risk losing recognition of "normal" NetBSD ELF
> > files, i.e. executables and shared libraries.
> Hmm, do you mean these notes:
>
> ```
> $ readelf -n /bin/cat
>
>
> Displaying notes found at file offset 0x0214 with length 0x0018:
> Owner Data size Description
> NetBSD 0x0004 IDENT 799005900 (7.99.59)
>
> Displaying notes found at file offset 0x022c with length 0x0014:
> Owner Data size Description
> NetBSD 0x0004 PaX <>
> ```
In particular the first one of these. On OpenBSD I just have a generic check
on the name which catches both these and the core file notes. But on NetBSD
those use different names.
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:563
+
+/// Generic (Linux, ...) specific Thread context from PT_NOTE segment
+/// 1) A Thread Context in a core file usually described by 3 NOTE entries.
krytarowski wrote:
> kettenis wrote:
> > A bit strange to call something both generic and specific...
> >
> > I think some of these note types originated on SVR4/Solaris, but I'm not
> > sure how much Linux deviated from that design through the years.
> Can we call it: Type1 core (as of now: NetBSD) and Type2 core (Linux,
> Android, FreeBSD, OpenBSD)?
>
> I don't care which would be 1 and which 2.
I'd just drop word "specific" from the comment. And OpenBSD will obviously be
handled in a similar way as NetBSD in the near future.
Repository:
rL LLVM
https://reviews.llvm.org/D32149
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r300837 - Skip TestLibCxxAtomic with gcc
Author: labath Date: Thu Apr 20 07:30:30 2017 New Revision: 300837 URL: http://llvm.org/viewvc/llvm-project?rev=300837&view=rev Log: Skip TestLibCxxAtomic with gcc older versions of libc++ (still used on some linux systems) are not compatible with gcc. Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py?rev=300837&r1=300836&r2=300837&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py Thu Apr 20 07:30:30 2017 @@ -23,6 +23,7 @@ class LibCxxAtomicTestCase(TestBase): var.SetPreferSyntheticValue(True) return var +@skipIf(compiler=["gcc"]) @add_test_categories(["libc++"]) def test(self): """Test that std::atomic as defined by libc++ is correctly printed by LLDB""" ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r300836 - Recompute ArchSpec core after MergeFrom
Author: labath
Date: Thu Apr 20 07:30:18 2017
New Revision: 300836
URL: http://llvm.org/viewvc/llvm-project?rev=300836&view=rev
Log:
Recompute ArchSpec core after MergeFrom
Summary:
MergeFrom was updating the architecture if the target triple did not
have it set. However, it was leaving the core field as invalid. This
resulted in assertion failures in core file tests as a missing core
meant we were unable to compute the address byte size properly.
Add a unit test for the new behaviour.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32221
Modified:
lldb/trunk/include/lldb/Core/ArchSpec.h
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/TestLinuxCoreThreads.py
lldb/trunk/source/Core/ArchSpec.cpp
lldb/trunk/unittests/Core/ArchSpecTest.cpp
Modified: lldb/trunk/include/lldb/Core/ArchSpec.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/ArchSpec.h?rev=300836&r1=300835&r2=300836&view=diff
==
--- lldb/trunk/include/lldb/Core/ArchSpec.h (original)
+++ lldb/trunk/include/lldb/Core/ArchSpec.h Thu Apr 20 07:30:18 2017
@@ -625,6 +625,7 @@ public:
protected:
bool IsEqualTo(const ArchSpec &rhs, bool exact_match) const;
+ void UpdateCore();
llvm::Triple m_triple;
Core m_core = kCore_invalid;
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py?rev=300836&r1=300835&r2=300836&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
Thu Apr 20 07:30:18 2017
@@ -39,7 +39,6 @@ class LinuxCoreTestCase(TestBase):
super(LinuxCoreTestCase, self).tearDown()
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with
r299199
@skipIf(triple='^mips')
def test_i386(self):
"""Test that lldb can read the process information from an i386 linux
core file."""
@@ -58,21 +57,18 @@ class LinuxCoreTestCase(TestBase):
self.do_test("linux-mips64el-gnuabi64", self._mips64_n64_pid,
self._mips_regions)
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with
r299199
@skipIf(triple='^mips')
def test_x86_64(self):
"""Test that lldb can read the process information from an x86_64
linux core file."""
self.do_test("linux-x86_64", self._x86_64_pid, self._x86_64_regions)
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with
r299199
@skipIf(triple='^mips')
def test_s390x(self):
"""Test that lldb can read the process information from an s390x linux
core file."""
self.do_test("linux-s390x", self._s390x_pid, self._s390x_regions)
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with
r299199
@skipIf(triple='^mips')
def test_same_pid_running(self):
"""Test that we read the information from the core correctly even if
we have a running
@@ -102,7 +98,6 @@ class LinuxCoreTestCase(TestBase):
self.RemoveTempFile("linux-x86_64-pid.core")
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with
r299199
@skipIf(triple='^mips')
def test_two_cores_same_pid(self):
"""Test that we handle the situation if we have two core files with
the same PID
@@ -132,7 +127,6 @@ class LinuxCoreTestCase(TestBase):
self.do_test("linux-x86_64", self._x86_64_pid, self._x86_64_regions)
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with
r299199
@skipIf(triple='^mips')
def test_FPR_SSE(self):
# check x86_64 core file
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py?rev=300836&r1=300835&r2=300836&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py
Thu Apr 20 07:30:18 2017
@@ -23,14 +23,12 @@ class GCoreTestCase(TestBase):
_
[Lldb-commits] [PATCH] D32221: Recompute ArchSpec core after MergeFrom
This revision was automatically updated to reflect the committed changes.
Closed by commit rL300836: Recompute ArchSpec core after MergeFrom (authored by
labath).
Changed prior to commit:
https://reviews.llvm.org/D32221?vs=95722&id=95941#toc
Repository:
rL LLVM
https://reviews.llvm.org/D32221
Files:
lldb/trunk/include/lldb/Core/ArchSpec.h
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/TestLinuxCoreThreads.py
lldb/trunk/source/Core/ArchSpec.cpp
lldb/trunk/unittests/Core/ArchSpecTest.cpp
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py
@@ -23,14 +23,12 @@
_x86_64_pid = 5669
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with r299199
@skipIf(triple='^mips')
def test_i386(self):
"""Test that lldb can read the process information from an i386 linux core file."""
self.do_test("linux-i386", self._i386_pid)
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with r299199
@skipIf(triple='^mips')
def test_x86_64(self):
"""Test that lldb can read the process information from an x86_64 linux core file."""
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
@@ -39,7 +39,6 @@
super(LinuxCoreTestCase, self).tearDown()
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with r299199
@skipIf(triple='^mips')
def test_i386(self):
"""Test that lldb can read the process information from an i386 linux core file."""
@@ -58,21 +57,18 @@
self.do_test("linux-mips64el-gnuabi64", self._mips64_n64_pid, self._mips_regions)
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with r299199
@skipIf(triple='^mips')
def test_x86_64(self):
"""Test that lldb can read the process information from an x86_64 linux core file."""
self.do_test("linux-x86_64", self._x86_64_pid, self._x86_64_regions)
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with r299199
@skipIf(triple='^mips')
def test_s390x(self):
"""Test that lldb can read the process information from an s390x linux core file."""
self.do_test("linux-s390x", self._s390x_pid, self._s390x_regions)
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with r299199
@skipIf(triple='^mips')
def test_same_pid_running(self):
"""Test that we read the information from the core correctly even if we have a running
@@ -102,7 +98,6 @@
self.RemoveTempFile("linux-x86_64-pid.core")
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with r299199
@skipIf(triple='^mips')
def test_two_cores_same_pid(self):
"""Test that we handle the situation if we have two core files with the same PID
@@ -132,7 +127,6 @@
self.do_test("linux-x86_64", self._x86_64_pid, self._x86_64_regions)
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with r299199
@skipIf(triple='^mips')
def test_FPR_SSE(self):
# check x86_64 core file
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/TestLinuxCoreThreads.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/TestLinuxCoreThreads.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/TestLinuxCoreThreads.py
@@ -27,14 +27,12 @@
_x86_64_tid = 5250
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with r299199
@skipIf(triple='^mips')
def test_i386(self):
"""Test that lldb can read the process information from an i386 linux core file."""
self.do_test("linux-i386", self._i386_pid, self._i386_tid)
@skipIf(oslist=['windows'])
-@skipIfDarwin # , fails started happening with r299199
@skipIf(triple='^mips')
def test_x86_64(self):
"""Test that lldb can read the pr
[Lldb-commits] [PATCH] D32149: Correct handling NetBSD core(5) files with threads
krytarowski added inline comments.
Comment at: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:1374
+else if ((note.n_name == LLDB_NT_OWNER_NETBSDCORE) &&
+ (note.n_type == LLDB_NT_NETBSD_NT_PROCINFO)) {
// Set the elf OS version to NetBSD. Also clear the vendor.
kettenis wrote:
> krytarowski wrote:
> > kettenis wrote:
> > > By making this change you risk losing recognition of "normal" NetBSD ELF
> > > files, i.e. executables and shared libraries.
> > Hmm, do you mean these notes:
> >
> > ```
> > $ readelf -n /bin/cat
> >
> >
> > Displaying notes found at file offset 0x0214 with length 0x0018:
> > Owner Data size Description
> > NetBSD0x0004 IDENT 799005900 (7.99.59)
> >
> > Displaying notes found at file offset 0x022c with length 0x0014:
> > Owner Data size Description
> > NetBSD0x0004 PaX <>
> > ```
> In particular the first one of these. On OpenBSD I just have a generic check
> on the name which catches both these and the core file notes. But on NetBSD
> those use different names.
I will test it and add switch to support both types of ELF files: core(5) and
executables.
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:563
+
+/// Generic (Linux, ...) specific Thread context from PT_NOTE segment
+/// 1) A Thread Context in a core file usually described by 3 NOTE entries.
kettenis wrote:
> krytarowski wrote:
> > kettenis wrote:
> > > A bit strange to call something both generic and specific...
> > >
> > > I think some of these note types originated on SVR4/Solaris, but I'm not
> > > sure how much Linux deviated from that design through the years.
> > Can we call it: Type1 core (as of now: NetBSD) and Type2 core (Linux,
> > Android, FreeBSD, OpenBSD)?
> >
> > I don't care which would be 1 and which 2.
> I'd just drop word "specific" from the comment. And OpenBSD will obviously be
> handled in a similar way as NetBSD in the near future.
Assuming that NetBSD and OpenBSD will share the same function - we can go
pickup appropriate name now.
As far as I can tell FreeBSD shares similar concept to Linux.
A thread specific data is defined by multiplication of the following notes:
```
FreeBSD 0x00e0 NT_PRSTATUS (prstatus structure)
FreeBSD 0x0200 NT_FPREGSET (floating point registers)
FreeBSD 0x0018 NT_THRMISC (thrmisc structure)
```
Repository:
rL LLVM
https://reviews.llvm.org/D32149
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32149: Correct handling NetBSD core(5) files with threads
labath added a comment.
In https://reviews.llvm.org/D32149#731920, @krytarowski wrote:
> In https://reviews.llvm.org/D32149#731887, @labath wrote:
>
> > A test would infinitely times more valuable then a demo script. What is the
> > tiniest core file you can produce on NetBSD? (on linux we've gotten them
> > down to about 20K) Then we could check that in and write a test for it...
>
>
> This is something I wanted to bring to the dev mailing list.
>
> I wanted to prepare at least three tests, if possible four:
>
> - one thread (if possible two variations: signal to one particular thread +
> signal to all threads)
> - multiple threads (signal to one particular thread + signal to all threads)
>
> And this in combination of all supported targets (x86_64, i386, etc).
>
> Emitting SIGABRT for such program gives core of size 97kilobytes:
>
> ``` int main(){for(;;);} ```
>
> I will write assembly programs for the above cases, without libc.
Cool, I am looking forward to the results.
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:795
+
+if ((note.n_name == "NetBSD-CORE") &&
+(note.n_type == NETBSD::NT_PROCINFO)) {
How about `StringRef name = note.n_name;`
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:803
+ m_auxv = DataExtractor(note_data);
+} else if ((note.n_name.substr(0, 12) == "NetBSD-CORE@")) {
+ switch (arch.GetMachine()) {
Then this can be
```
else if (name.consume_front("NetBSD-CORE@")) {
...
if (name.getAsInteger(0, tid))
error...
```
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:848
+ if (siglwp == 0) {
+std::for_each(
+m_thread_data.begin(), m_thread_data.end(),
`for (auto &data: m_thread_data) data.signo = signo` seems shorter, more
understandable, and consistent with other usages in this file.
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:856
+
+for (auto it = m_thread_data.begin(); it != m_thread_data.end(); ++it) {
+ if (it->tid == siglwp) {
This could also be a range-based for.
Repository:
rL LLVM
https://reviews.llvm.org/D32149
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D32149: Correct handling NetBSD core(5) files with threads
Note that getAsInteger returns false on success, so be careful!
On Thu, Apr 20, 2017 at 6:09 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath added a comment.
>
> In https://reviews.llvm.org/D32149#731920, @krytarowski wrote:
>
> > In https://reviews.llvm.org/D32149#731887, @labath wrote:
> >
> > > A test would infinitely times more valuable then a demo script. What
> is the tiniest core file you can produce on NetBSD? (on linux we've gotten
> them down to about 20K) Then we could check that in and write a test for
> it...
> >
> >
> > This is something I wanted to bring to the dev mailing list.
> >
> > I wanted to prepare at least three tests, if possible four:
> >
> > - one thread (if possible two variations: signal to one particular
> thread + signal to all threads)
> > - multiple threads (signal to one particular thread + signal to all
> threads)
> >
> > And this in combination of all supported targets (x86_64, i386, etc).
> >
> > Emitting SIGABRT for such program gives core of size 97kilobytes:
> >
> > ``` int main(){for(;;);} ```
> >
> > I will write assembly programs for the above cases, without libc.
>
>
> Cool, I am looking forward to the results.
>
>
>
>
> Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:795
> +
> +if ((note.n_name == "NetBSD-CORE") &&
> +(note.n_type == NETBSD::NT_PROCINFO)) {
>
> How about `StringRef name = note.n_name;`
>
>
>
> Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:803
> + m_auxv = DataExtractor(note_data);
> +} else if ((note.n_name.substr(0, 12) == "NetBSD-CORE@")) {
> + switch (arch.GetMachine()) {
>
> Then this can be
> ```
> else if (name.consume_front("NetBSD-CORE@")) {
> ...
> if (name.getAsInteger(0, tid))
> error...
> ```
>
>
>
> Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:848
> + if (siglwp == 0) {
> +std::for_each(
> +m_thread_data.begin(), m_thread_data.end(),
>
> `for (auto &data: m_thread_data) data.signo = signo` seems shorter, more
> understandable, and consistent with other usages in this file.
>
>
>
> Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:856
> +
> +for (auto it = m_thread_data.begin(); it != m_thread_data.end();
> ++it) {
> + if (it->tid == siglwp) {
>
> This could also be a range-based for.
>
>
> Repository:
> rL LLVM
>
> https://reviews.llvm.org/D32149
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32022: Fix backtrace of noreturn functions situated at the end of a module
labath added a comment. Jim, Jason, could one of you take a look at this please? This part of the code is not really my specialty, so I'd appreciate your thoughts on this. https://reviews.llvm.org/D32022 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32137: [Utility] Placate another GCC warning
davide added a comment. In https://reviews.llvm.org/D32137#731727, @labath wrote: > Thanks for digging into this, I've learned something new today. Fixing this > with a cast seems reasonable then. Me too, apparently C++ integer promotion is less obvious than I thought ;) https://reviews.llvm.org/D32137 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32295: [RFC] Fix crash in expression evaluation
labath created this revision.
Herald added a subscriber: aprantl.
Since r299449 "Make RuntimeDyld honor the ProcessAllSections flag." we
have been experiencing an assertion failure when evaluating expressions
on linux.
Based on my investigation, the sequence of events is as follows:
- lldb sets the ProcessAllSections flag
- RuntimeDyld starts loading all sections, .debug_frame in particular
- RuntimeDyld ask lldb for an address of the section, lldb provides an
address somewhere in its 64-bit address space
- RuntimeDyld proceeds to resolve relocations in this section
In my simple example the section consists of two entries: one CIE and
one FDE. It also contains a relocation of type R_X86_64_32 pointing from
the FDE to its CIE.
- RuntimeDyld tries to apply the relocation, but fails because the load
address of the section has high bits set
Removing the ProcessAllSections flag makes the assert go away (and
re-introduces the pre-r299449 lldb behavior of ignoring these sections),
but it seems that this could be just masking a bigger issue. However, my
knowledge of this part of the code is limited, so I don't know what the
actual issue should be:
- This is an intra-section relocation, and dwarf explicitly says that
this should be a relative offset. Should the relocation have been
emitted in the first place ? Is it the right relocation type this use
case?
- Is RuntimeDyld picking the wrong address to relocate?
- Should lldb be somehow detecting this situation and set the load
address of the section to zero to get this right?
I'd appreciate any input or pointers. The bug can be reproduced (on
linux) with:
echo 'int main() { return 0; }' >a.c
cc -g a.c
bin/lldb a.out
b main
run
expr main()
https://reviews.llvm.org/D32295
Files:
source/Expression/IRExecutionUnit.cpp
Index: source/Expression/IRExecutionUnit.cpp
===
--- source/Expression/IRExecutionUnit.cpp
+++ source/Expression/IRExecutionUnit.cpp
@@ -333,10 +333,6 @@
m_execution_engine_ap->setObjectCache(m_object_cache_ap.get());
}
- // Make sure we see all sections, including ones that don't have
- // relocations...
- m_execution_engine_ap->setProcessAllSections(true);
-
m_execution_engine_ap->DisableLazyCompilation();
for (llvm::Function &function : *m_module) {
Index: source/Expression/IRExecutionUnit.cpp
===
--- source/Expression/IRExecutionUnit.cpp
+++ source/Expression/IRExecutionUnit.cpp
@@ -333,10 +333,6 @@
m_execution_engine_ap->setObjectCache(m_object_cache_ap.get());
}
- // Make sure we see all sections, including ones that don't have
- // relocations...
- m_execution_engine_ap->setProcessAllSections(true);
-
m_execution_engine_ap->DisableLazyCompilation();
for (llvm::Function &function : *m_module) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r300845 - [Utility] Placate another GCC warning.
Author: davide Date: Thu Apr 20 09:45:33 2017 New Revision: 300845 URL: http://llvm.org/viewvc/llvm-project?rev=300845&view=rev Log: [Utility] Placate another GCC warning. Differential Revision: https://reviews.llvm.org/D32137 Modified: lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.cpp Modified: lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.cpp?rev=300845&r1=300844&r2=300845&view=diff == --- lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.cpp (original) +++ lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.cpp Thu Apr 20 09:45:33 2017 @@ -55,9 +55,10 @@ RegisterContextPOSIX_mips64::RegisterCon m_registers_count[i] = reg_set_ptr->num_registers; } - assert(m_num_registers == m_registers_count[gpr_registers_count] + -m_registers_count[fpr_registers_count] + -m_registers_count[msa_registers_count]); + assert(m_num_registers == + static_cast(m_registers_count[gpr_registers_count] + + m_registers_count[fpr_registers_count] + + m_registers_count[msa_registers_count])); // elf-core yet to support ReadFPR() ProcessSP base = CalculateProcess(); ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32137: [Utility] Placate another GCC warning
This revision was automatically updated to reflect the committed changes. Closed by commit rL300845: [Utility] Placate another GCC warning. (authored by davide). Changed prior to commit: https://reviews.llvm.org/D32137?vs=95485&id=95961#toc Repository: rL LLVM https://reviews.llvm.org/D32137 Files: lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.cpp Index: lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.cpp === --- lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.cpp +++ lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.cpp @@ -55,9 +55,10 @@ m_registers_count[i] = reg_set_ptr->num_registers; } - assert(m_num_registers == m_registers_count[gpr_registers_count] + -m_registers_count[fpr_registers_count] + -m_registers_count[msa_registers_count]); + assert(m_num_registers == + static_cast(m_registers_count[gpr_registers_count] + + m_registers_count[fpr_registers_count] + + m_registers_count[msa_registers_count])); // elf-core yet to support ReadFPR() ProcessSP base = CalculateProcess(); Index: lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.cpp === --- lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.cpp +++ lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.cpp @@ -55,9 +55,10 @@ m_registers_count[i] = reg_set_ptr->num_registers; } - assert(m_num_registers == m_registers_count[gpr_registers_count] + -m_registers_count[fpr_registers_count] + -m_registers_count[msa_registers_count]); + assert(m_num_registers == + static_cast(m_registers_count[gpr_registers_count] + + m_registers_count[fpr_registers_count] + + m_registers_count[msa_registers_count])); // elf-core yet to support ReadFPR() ProcessSP base = CalculateProcess(); ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r300853 - Resurrect LLDB Standalone build on NetBSD
Author: kamil Date: Thu Apr 20 11:35:36 2017 New Revision: 300853 URL: http://llvm.org/viewvc/llvm-project?rev=300853&view=rev Log: Resurrect LLDB Standalone build on NetBSD Include CheckIncludeFile for check_include_file() in CMake. Detect in CMake. This header is available on NetBSD. Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=300853&r1=300852&r2=300853&view=diff == --- lldb/trunk/cmake/modules/LLDBConfig.cmake (original) +++ lldb/trunk/cmake/modules/LLDBConfig.cmake Thu Apr 20 11:35:36 2017 @@ -433,7 +433,9 @@ endif() find_package(Backtrace) +include(CheckIncludeFile) check_include_file(termios.h HAVE_TERMIOS_H) +check_include_file(sys/event.h HAVE_SYS_EVENT_H) # These checks exist in LLVM's configuration, so I want to match the LLVM names # so that the check isn't duplicated, but we translate them into the LLDB names ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r300862 - Changed a use of APInt::getSignBit to APInt::getSignMask.
Author: spyffe
Date: Thu Apr 20 13:07:51 2017
New Revision: 300862
URL: http://llvm.org/viewvc/llvm-project?rev=300862&view=rev
Log:
Changed a use of APInt::getSignBit to APInt::getSignMask.
Modified:
lldb/trunk/source/Core/Scalar.cpp
Modified: lldb/trunk/source/Core/Scalar.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Scalar.cpp?rev=300862&r1=300861&r2=300862&view=diff
==
--- lldb/trunk/source/Core/Scalar.cpp (original)
+++ lldb/trunk/source/Core/Scalar.cpp Thu Apr 20 13:07:51 2017
@@ -2745,7 +2745,7 @@ bool Scalar::SignExtend(uint32_t sign_bi
if (max_bit_pos == sign_bit_pos)
return true;
else if (sign_bit_pos < (max_bit_pos - 1)) {
-llvm::APInt sign_bit = llvm::APInt::getSignBit(sign_bit_pos + 1);
+llvm::APInt sign_bit = llvm::APInt::getSignMask(sign_bit_pos + 1);
llvm::APInt bitwize_and = m_integer & sign_bit;
if (bitwize_and.getBoolValue()) {
const llvm::APInt mask =
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32306: Remove lock from ConstString::GetLength
scott.smith created this revision.
ConstStrings are immutable, so there is no need to grab even a reader lock in
order to read the length field.
Repository:
rL LLVM
https://reviews.llvm.org/D32306
Files:
source/Utility/ConstString.cpp
Index: source/Utility/ConstString.cpp
===
--- source/Utility/ConstString.cpp
+++ source/Utility/ConstString.cpp
@@ -42,10 +42,10 @@
return *reinterpret_cast(ptr);
}
- size_t GetConstCStringLength(const char *ccstr) const {
+ static size_t GetConstCStringLength(const char *ccstr) {
if (ccstr != nullptr) {
- const uint8_t h = hash(llvm::StringRef(ccstr));
- llvm::sys::SmartScopedReader rlock(m_string_pools[h].m_mutex);
+ // Since the entry is read only, and we derive the entry entirely from
the
+ // pointer, we don't need the lock.
const StringPoolEntryType &entry = GetStringMapEntryFromKeyData(ccstr);
return entry.getKey().size();
}
@@ -218,10 +218,8 @@
if (m_string == rhs.m_string)
return false;
- llvm::StringRef lhs_string_ref(m_string,
- StringPool().GetConstCStringLength(m_string));
- llvm::StringRef rhs_string_ref(
- rhs.m_string, StringPool().GetConstCStringLength(rhs.m_string));
+ llvm::StringRef lhs_string_ref(GetStringRef());
+ llvm::StringRef rhs_string_ref(rhs.GetStringRef());
// If both have valid C strings, then return the comparison
if (lhs_string_ref.data() && rhs_string_ref.data())
@@ -240,7 +238,7 @@
}
size_t ConstString::GetLength() const {
- return StringPool().GetConstCStringLength(m_string);
+ return Pool::GetConstCStringLength(m_string);
}
bool ConstString::Equals(const ConstString &lhs, const ConstString &rhs,
@@ -255,10 +253,8 @@
return false;
// perform case insensitive equality test
- llvm::StringRef lhs_string_ref(
- lhs.m_string, StringPool().GetConstCStringLength(lhs.m_string));
- llvm::StringRef rhs_string_ref(
- rhs.m_string, StringPool().GetConstCStringLength(rhs.m_string));
+ llvm::StringRef lhs_string_ref(lhs.GetStringRef());
+ llvm::StringRef rhs_string_ref(rhs.GetStringRef());
return lhs_string_ref.equals_lower(rhs_string_ref);
}
@@ -270,10 +266,8 @@
if (lhs_cstr == rhs_cstr)
return 0;
if (lhs_cstr && rhs_cstr) {
-llvm::StringRef lhs_string_ref(
-lhs_cstr, StringPool().GetConstCStringLength(lhs_cstr));
-llvm::StringRef rhs_string_ref(
-rhs_cstr, StringPool().GetConstCStringLength(rhs_cstr));
+llvm::StringRef lhs_string_ref(lhs.GetStringRef());
+llvm::StringRef rhs_string_ref(rhs.GetStringRef());
if (case_sensitive) {
return lhs_string_ref.compare(rhs_string_ref);
Index: source/Utility/ConstString.cpp
===
--- source/Utility/ConstString.cpp
+++ source/Utility/ConstString.cpp
@@ -42,10 +42,10 @@
return *reinterpret_cast(ptr);
}
- size_t GetConstCStringLength(const char *ccstr) const {
+ static size_t GetConstCStringLength(const char *ccstr) {
if (ccstr != nullptr) {
- const uint8_t h = hash(llvm::StringRef(ccstr));
- llvm::sys::SmartScopedReader rlock(m_string_pools[h].m_mutex);
+ // Since the entry is read only, and we derive the entry entirely from the
+ // pointer, we don't need the lock.
const StringPoolEntryType &entry = GetStringMapEntryFromKeyData(ccstr);
return entry.getKey().size();
}
@@ -218,10 +218,8 @@
if (m_string == rhs.m_string)
return false;
- llvm::StringRef lhs_string_ref(m_string,
- StringPool().GetConstCStringLength(m_string));
- llvm::StringRef rhs_string_ref(
- rhs.m_string, StringPool().GetConstCStringLength(rhs.m_string));
+ llvm::StringRef lhs_string_ref(GetStringRef());
+ llvm::StringRef rhs_string_ref(rhs.GetStringRef());
// If both have valid C strings, then return the comparison
if (lhs_string_ref.data() && rhs_string_ref.data())
@@ -240,7 +238,7 @@
}
size_t ConstString::GetLength() const {
- return StringPool().GetConstCStringLength(m_string);
+ return Pool::GetConstCStringLength(m_string);
}
bool ConstString::Equals(const ConstString &lhs, const ConstString &rhs,
@@ -255,10 +253,8 @@
return false;
// perform case insensitive equality test
- llvm::StringRef lhs_string_ref(
- lhs.m_string, StringPool().GetConstCStringLength(lhs.m_string));
- llvm::StringRef rhs_string_ref(
- rhs.m_string, StringPool().GetConstCStringLength(rhs.m_string));
+ llvm::StringRef lhs_string_ref(lhs.GetStringRef());
+ llvm::StringRef rhs_string_ref(rhs.GetStringRef());
return lhs_string_ref.equals_lower(rhs_string_ref);
}
@@ -270,10 +266,8 @@
if (lhs_cstr == rhs_cstr)
return 0;
if (lhs_cstr && rhs_cstr) {
-llvm::StringRef lhs_string_ref(
-lhs_cstr, StringPool().GetConstCStringLength(lhs_cstr));
-llvm::StringRef rh
[Lldb-commits] [PATCH] D32295: [RFC] Fix crash in expression evaluation
lhames accepted this revision. lhames added a comment. This revision is now accepted and ready to land. Approving the LLDB/Linux working again. Thanks for digging in to this Pavel. Greg Clayton appears to have hit the same issue recently too. Digging through bugs.llvm.org, it looks like this might be: https://bugs.llvm.org/show_bug.cgi?id=20457 . If we can fix this it would allow us to break in and debug JIT'd expressions on Linux, which would be cool. https://reviews.llvm.org/D32295 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32022: Fix backtrace of noreturn functions situated at the end of a module
jasonmolenda added a comment. Sorry Pavel, I kept meaning to look at this patch this week but hadn't yet. I will later today. When I read over your description of the problem, it sounded like a good fix - haven't looked at the code yet. https://reviews.llvm.org/D32022 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r300902 - Add an example command to toggle between disassembly-only and source mode.
Author: jingham
Date: Thu Apr 20 16:51:27 2017
New Revision: 300902
URL: http://llvm.org/viewvc/llvm-project?rev=300902&view=rev
Log:
Add an example command to toggle between disassembly-only and source mode.
Sometimes you are debugging in source, but you really only want to see
the disassembly. That's easy to do but you have to set a few variables.
This command toggles between your old values, and a disassembly only mode.
Added:
lldb/trunk/examples/python/disassembly_mode.py
Added: lldb/trunk/examples/python/disassembly_mode.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/examples/python/disassembly_mode.py?rev=300902&view=auto
==
--- lldb/trunk/examples/python/disassembly_mode.py (added)
+++ lldb/trunk/examples/python/disassembly_mode.py Thu Apr 20 16:51:27 2017
@@ -0,0 +1,48 @@
+""" Adds the 'toggle-disassembly' command to switch you into a disassembly
only mode """
+import lldb
+
+class DisassemblyMode:
+def __init__(self, debugger, unused):
+self.dbg = debugger
+self.interp = debugger.GetCommandInterpreter()
+self.store_state()
+self.mode_off = True
+
+def store_state(self):
+self.dis_count = self.get_string_value("stop-disassembly-count")
+self.dis_display = self.get_string_value("stop-disassembly-display")
+self.before_count = self.get_string_value("stop-line-count-before")
+self.after_count = self.get_string_value("stop-line-count-after")
+
+def get_string_value(self, setting):
+result = lldb.SBCommandReturnObject()
+self.interp.HandleCommand("settings show " + setting, result)
+value = result.GetOutput().split(" = ")[1].rstrip("\n")
+return value
+
+def set_value(self, setting, value):
+result = lldb.SBCommandReturnObject()
+self.interp.HandleCommand("settings set " + setting + " " + value,
result)
+
+def __call__(self, debugger, command, exe_ctx, result):
+if self.mode_off:
+self.mode_off = False
+self.store_state()
+self.set_value("stop-disassembly-display","always")
+self.set_value("stop-disassembly-count", "8")
+self.set_value("stop-line-count-before", "0")
+self.set_value("stop-line-count-after", "0")
+result.AppendMessage("Disassembly mode on.")
+else:
+self.mode_off = True
+self.set_value("stop-disassembly-display",self.dis_display)
+self.set_value("stop-disassembly-count", self.dis_count)
+self.set_value("stop-line-count-before", self.before_count)
+self.set_value("stop-line-count-after", self.after_count)
+result.AppendMessage("Disassembly mode off.")
+
+def get_short_help(self):
+return "Toggles between a disassembly only mode and normal source
mode\n"
+
+def __lldb_init_module(debugger, unused):
+debugger.HandleCommand("command script add -c
disassembly_mode.DisassemblyMode toggle-disassembly")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32316: Change UniqueCStringMap to use ConstString as the key
scott.smith created this revision.
UniqueCStringMap "sorts" the entries for fast lookup, but really it only cares
about uniqueness. ConstString can be compared by pointer along, rather than
with strcmp, resulting in much faster comparisons. Change the interface to
take ConstString instead, and propagate use of the type to the callers where
appropriate.
Repository:
rL LLVM
https://reviews.llvm.org/D32316
Files:
include/lldb/Core/UniqueCStringMap.h
include/lldb/Interpreter/Property.h
include/lldb/Symbol/ObjectFile.h
include/lldb/Utility/ConstString.h
source/Interpreter/OptionValueEnumeration.cpp
source/Interpreter/OptionValueProperties.cpp
source/Interpreter/Property.cpp
source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
source/Plugins/ObjectFile/ELF/ObjectFileELF.h
source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
source/Plugins/SymbolFile/DWARF/NameToDIE.h
source/Symbol/ClangASTContext.cpp
source/Symbol/GoASTContext.cpp
source/Symbol/Symtab.cpp
Index: source/Symbol/Symtab.cpp
===
--- source/Symbol/Symtab.cpp
+++ source/Symbol/Symtab.cpp
@@ -263,16 +263,15 @@
continue;
const Mangled &mangled = symbol->GetMangled();
- entry.cstring = mangled.GetMangledName().GetStringRef();
- if (!entry.cstring.empty()) {
+ entry.cstring = mangled.GetMangledName();
+ if (entry.cstring) {
m_name_to_index.Append(entry);
if (symbol->ContainsLinkerAnnotations()) {
// If the symbol has linker annotations, also add the version without
// the annotations.
- entry.cstring = ConstString(m_objfile->StripLinkerSymbolAnnotations(
- entry.cstring))
- .GetStringRef();
+ entry.cstring = m_objfile->StripLinkerSymbolAnnotations(
+ entry.cstring);
m_name_to_index.Append(entry);
}
@@ -290,9 +289,8 @@
{
CPlusPlusLanguage::MethodName cxx_method(
mangled.GetDemangledName(lldb::eLanguageTypeC_plus_plus));
-entry.cstring =
-ConstString(cxx_method.GetBasename()).GetStringRef();
-if (!entry.cstring.empty()) {
+entry.cstring = ConstString(cxx_method.GetBasename());
+if (entry.cstring) {
// ConstString objects permanently store the string in the pool so
// calling
// GetCString() on the value gets us a const char * that will
@@ -341,17 +339,15 @@
}
}
- entry.cstring =
- mangled.GetDemangledName(symbol->GetLanguage()).GetStringRef();
- if (!entry.cstring.empty()) {
+ entry.cstring = mangled.GetDemangledName(symbol->GetLanguage());
+ if (entry.cstring) {
m_name_to_index.Append(entry);
if (symbol->ContainsLinkerAnnotations()) {
// If the symbol has linker annotations, also add the version without
// the annotations.
- entry.cstring = ConstString(m_objfile->StripLinkerSymbolAnnotations(
- entry.cstring))
- .GetStringRef();
+ entry.cstring = m_objfile->StripLinkerSymbolAnnotations(
+ entry.cstring);
m_name_to_index.Append(entry);
}
}
@@ -359,15 +355,15 @@
// If the demangled name turns out to be an ObjC name, and
// is a category name, add the version without categories to the index
// too.
- ObjCLanguage::MethodName objc_method(entry.cstring, true);
+ ObjCLanguage::MethodName objc_method(entry.cstring.GetStringRef(), true);
if (objc_method.IsValid(true)) {
-entry.cstring = objc_method.GetSelector().GetStringRef();
+entry.cstring = objc_method.GetSelector();
m_selector_to_index.Append(entry);
ConstString objc_method_no_category(
objc_method.GetFullNameWithoutCategory(true));
if (objc_method_no_category) {
- entry.cstring = objc_method_no_category.GetStringRef();
+ entry.cstring = objc_method_no_category;
m_name_to_index.Append(entry);
}
}
@@ -444,15 +440,14 @@
const Mangled &mangled = symbol->GetMangled();
if (add_demangled) {
-entry.cstring =
-mangled.GetDemangledName(symbol->GetLanguage()).GetStringRef();
-if (!entry.cstring.empty())
+entry.cstring = mangled.GetDemangledName(symbol->GetLanguage());
+if (entry.cstring)
name_to_index_map.Append(entry);
}
if (add_mangled) {
-entry.cstring = mangled.GetMangledName().GetStringRef(
[Lldb-commits] Buildbot numbers for the week of 04/02/2017 - 04/08/2017
Hello everyone, Below are some buildbot numbers for the week of 04/02/2017 - 04/08/2017. Please see the same data in attached csv files: The longest time each builder was red during the last week; "Status change ratio" by active builder (percent of builds that changed the builder status from greed to red or from red to green); Count of commits by project; Number of completed builds, failed builds and average build time for successful builds per active builder; Average waiting time for a revision to get build result per active builder (response time). Thanks Galina The longest time each builder was red during the last week: buildername | was_red +-- clang-x64-ninja-win7 | 131:11:54 lldb-amd64-ninja-freebsd11 | 74:30:52 lldb-x86_64-ubuntu-14.04-android | 42:01:22 sanitizer-windows | 40:01:49 clang-lld-x86_64-2stage| 30:53:01 clang-with-lto-ubuntu | 29:17:54 sanitizer-x86_64-linux-autoconf| 25:11:10 clang-s390x-linux | 24:04:42 clang-ppc64le-linux-lnt| 24:03:16 clang-ppc64le-linux-multistage | 22:52:11 lldb-x86_64-ubuntu-14.04-cmake | 21:35:51 clang-ppc64be-linux-lnt| 16:00:25 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 15:14:08 perf-x86_64-penryn-O3 | 12:06:38 clang-cmake-armv7-a15-selfhost | 11:04:31 clang-cmake-mipsel | 10:49:21 perf-x86_64-penryn-O3-polly| 10:36:54 clang-x86-windows-msvc2015 | 09:25:23 llvm-clang-x86_64-expensive-checks-win | 09:18:55 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 09:01:11 libcxx-libcxxabi-libunwind-aarch64-linux | 08:43:12 perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 08:20:05 sanitizer-x86_64-linux-fast| 08:06:20 sanitizer-ppc64be-linux| 08:02:19 perf-x86_64-penryn-O3-polly-before-vectorizer | 08:01:14 clang-cmake-aarch64-full | 07:06:55 clang-cmake-armv7-a15-selfhost-neon| 06:53:09 clang-cmake-mips | 06:47:06 sanitizer-x86_64-linux | 06:39:15 perf-x86_64-penryn-O3-polly-parallel-fast | 06:31:00 sanitizer-x86_64-linux-bootstrap | 06:24:43 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 | 06:05:44 perf-x86_64-penryn-O3-polly-unprofitable | 05:51:43 llvm-mips-linux| 05:50:22 clang-cmake-thumbv7-a15-full-sh| 05:41:46 clang-ppc64be-linux-multistage | 05:33:48 clang-cmake-aarch64-lld| 05:31:08 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 05:18:18 perf-x86_64-penryn-O3-polly-fast | 05:13:25 polly-amd64-linux | 05:05:36 clang-native-arm-lnt | 05:01:41 clang-cmake-armv7-a15 | 04:56:45 clang-cmake-aarch64-42vma | 04:49:19 libomp-gcc-x86_64-linux-debian | 04:24:54 polly-arm-linux| 04:13:38 libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan | 03:38:26 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 03:37:44 libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 03:34:34 libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu | 03:30:54 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 03:03:33 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z | 03:02:27 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 | 03:00:22 clang-cmake-armv7-a15-full | 02:49:28 lldb-windows7-android | 02:45:27 clang-cmake-thumbv7-a15| 02:45:26 clang-x86_64-linux-selfhost-modules-2 | 02:41:11 clang-ppc64le-linux| 02:35:20 clang-cuda-build | 02:31:10 clang-cmake-aarch64-39vma | 02:27:15 clang-cmake-aarch64-quick
[Lldb-commits] Buildbot numbers for the week of 04/09/2017 - 04/15/2017
Hello everyone, Below are some buildbot numbers for the last week of 04/09/2017 - 04/15/2017. Please see the same data in attached csv files: The longest time each builder was red during the last week; "Status change ratio" by active builder (percent of builds that changed the builder status from greed to red or from red to green); Count of commits by project; Number of completed builds, failed builds and average build time for successful builds per active builder; Average waiting time for a revision to get build result per active builder (response time). Thanks Galina The longest time each builder was red during the last week: buildername | was_red +- clang-x86_64-linux-selfhost-modules| 76:17:27 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 52:20:18 clang-lld-x86_64-2stage| 50:37:55 clang-x86_64-linux-selfhost-modules-2 | 47:24:53 sanitizer-ppc64le-linux| 42:59:32 clang-cmake-thumbv7-a15-full-sh| 39:55:31 clang-ppc64be-linux-multistage | 28:48:14 clang-x64-ninja-win7 | 27:23:55 clang-x86-windows-msvc2015 | 27:13:14 clang-cmake-armv7-a15-selfhost-neon| 26:33:39 clang-cmake-armv7-a15-selfhost | 24:38:47 sanitizer-x86_64-linux-bootstrap | 23:18:49 clang-cmake-aarch64-lld| 23:12:21 clang-ppc64le-linux-multistage | 23:10:30 clang-with-lto-ubuntu | 23:07:50 clang-cmake-aarch64-full | 22:25:25 llvm-clang-x86_64-expensive-checks-win | 18:08:11 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 18:07:41 lldb-x86_64-ubuntu-14.04-android | 16:30:53 lldb-x86_64-darwin-13.4| 10:25:03 lldb-x86_64-ubuntu-14.04-cmake | 10:01:41 lldb-windows7-android | 10:00:29 clang-cmake-aarch64-39vma | 08:42:25 clang-cmake-aarch64-42vma | 08:41:55 clang-cmake-armv7-a15-full | 08:34:15 sanitizer-x86_64-linux-autoconf| 07:43:05 sanitizer-ppc64be-linux| 07:41:12 perf-x86_64-penryn-O3 | 06:57:03 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 06:21:15 perf-x86_64-penryn-O3-polly| 06:19:15 clang-cmake-thumbv7-a15| 06:11:09 clang-cmake-armv7-a15 | 06:11:02 clang-hexagon-elf | 06:05:43 polly-arm-linux| 05:59:33 llvm-hexagon-elf | 05:59:32 clang-cmake-aarch64-quick | 05:59:09 lld-x86_64-darwin13| 05:55:08 perf-x86_64-penryn-O3-polly-fast | 05:20:31 clang-cmake-mips | 05:10:18 clang-cmake-mipsel | 04:53:45 polly-amd64-linux | 04:38:23 clang-ppc64be-linux-lnt| 04:31:54 lldb-x86_64-ubuntu-14.04-buildserver | 03:35:44 clang-ppc64le-linux| 03:30:42 lldb-amd64-ninja-netbsd7 | 03:26:29 llvm-sphinx-docs | 03:21:14 llvm-mips-linux| 03:21:02 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 | 02:48:01 clang-ppc64le-linux-lnt| 02:47:56 clang-ppc64be-linux| 02:41:03 libcxx-libcxxabi-libunwind-arm-linux-noexceptions | 02:38:34 sanitizer-x86_64-linux-fast| 02:37:50 lldb-x86-windows-msvc2015 | 02:28:17 perf-x86_64-penryn-O3-polly-parallel-fast | 02:21:54 perf-x86_64-penryn-O3-polly-unprofitable | 02:15:47 lldb-amd64-ninja-freebsd11 | 02:05:38 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 02:00:19 perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 01:53:15 sanitizer-windows | 01:44:58 clang-s390x-linux
[Lldb-commits] [PATCH] D32316: Change UniqueCStringMap to use ConstString as the key
jasonmolenda added a comment. I'd recommend Greg Clayton as a reviewer. Repository: rL LLVM https://reviews.llvm.org/D32316 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32316: Change UniqueCStringMap to use ConstString as the key
jasonmolenda added a comment. You should also add lldb-commits as a subscriber, fwiw, so comments/questions/etc are cc:'ed to the -commits list. Repository: rL LLVM https://reviews.llvm.org/D32316 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32295: [RFC] Fix crash in expression evaluation
clayborg requested changes to this revision. clayborg added a comment. This revision now requires changes to proceed. This will break the Swift REPL as it relies on debug info and we won't be told about the ".debug_XXX" or "__debug_XXX" sections if we disable this. Jim or Sean should verify this and comment in the bug. https://reviews.llvm.org/D32295 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32316: Change UniqueCStringMap to use ConstString as the key
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Very close. A few misuses of ConstString and this will be good to go.
Comment at: include/lldb/Interpreter/Property.h:43
+ ConstString GetName() const { return m_name; }
+ ConstString GetDescription() const { return m_description; }
This shouldn't be const-ified, Only names of things like variables,
enumerators, typenames, paths, and other strings that are going to be uniqued
should go into the ConstStringPool
Comment at: include/lldb/Symbol/ObjectFile.h:569
/// Some object files may have an identifier string embedded in them,
- /// e.g. in a Mach-O core file using the LC_IDENT load command (which
+ /// e.g. in a Mach-O core file using the LC_IDENT load command (which
/// is obsolete, but can still be found in some old files)
Remove whitespace changes. Do as separate checkin if desired. This helps keep
the noise down in the change in case things need to be cherry picked,.
Comment at: include/lldb/Symbol/ObjectFile.h:576-577
//--
- virtual std::string GetIdentifierString () {
- return std::string();
+ virtual std::string GetIdentifierString () {
+ return std::string();
}
Remove whitespace changes. Do as separate checkin if desired. This helps keep
the noise down in the change in case things need to be cherry picked,.
Comment at: include/lldb/Symbol/ObjectFile.h:583
/// "binary" in the core file. lldb can iterate over the pages looking
- /// for a valid binary, but some core files may have metadata
+ /// for a valid binary, but some core files may have metadata
/// describing where the main binary is exactly which removes ambiguity
Remove whitespace changes. Do as separate checkin if desired. This helps keep
the noise down in the change in case things need to be cherry picked,.
Comment at: include/lldb/Symbol/ObjectFile.h:808-811
+ virtual ConstString
+ StripLinkerSymbolAnnotations(ConstString symbol_name) const {
+return symbol_name;
}
This actually doesn't need to change. Since it is merely stripping off parts of
the string, this should really stay as a StringRef and it should return a
StringRef. Change to use StringRef for return and for argument, or revert.
Comment at: include/lldb/Utility/ConstString.h:481
+ char operator[](size_t Index) const {
+assert(Index < GetLength() && "Invalid index!");
+return m_string[Index];
I really don't like the prospect of crashing the debugger if someone calls this
with an invalid index. Many people ship with asserts on. I would either make it
safe if it is indeed just for reporting or remove the assert.
Comment at: source/Interpreter/Property.cpp:252
if (dump_desc) {
- llvm::StringRef desc = GetDescription();
- if (!desc.empty())
+ ConstString desc = GetDescription();
+ if (desc)
Revert this. Description shouldn't be a ConstString.
Comment at: source/Interpreter/Property.cpp:269
return;
- llvm::StringRef desc = GetDescription();
+ llvm::StringRef desc = GetDescription().GetStringRef();
Revert this. Description shouldn't be a ConstString.
Comment at: source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp:324-326
+ ConstString key_cstr = m_impl.GetCStringAtIndex(item);
+ if (strstr(type_name.GetCString(), key_cstr.GetCString())) {
+count += AppendReplacements(type_name, key_cstr, equivalents);
StringRef is better to use for modifying simple strings and looking for things.
Actually looking at this class it is using ConstString all over the place for
putting strings together. For creating strings we should use
lldb_private::StreamString. For stripping stuff off and grabbing just part of a
string, seeing if a string starts with, ends with, contains, etc,
llvm::StringRef. So I would vote to just change it back, or fix the entire
class to use lldb_private::StreamString
Comment at: source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp:345-348
+ uint32_t AppendReplacements(ConstString original,
+ ConstString matching_key,
std::vector &equivalents) {
+std::string matching_key_str(matching_key.GetCString());
Ditto
Comment at: source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp:354
match != nullptr; match = m_impl.FindNextValueForName(match)) {
- std::string target(original);
+ std::string target(original.GetCString());
std::string equiv_class(match->value.AsCString());
Ditto
==
[Lldb-commits] [PATCH] D32022: Fix backtrace of noreturn functions situated at the end of a module
jasonmolenda added a comment. Hi Pavel, I'd document the new flag in include/lldb/Core/Address.h where we have documentation for the other flags being used. It seems like we're fixing this a little indirectly, and I'm not sure it's the best approach. I want to make sure I understand the situation correctly. Say we have an object file with three sections s1 0..99 (offset 0, size 100) s2 100..199 (offset 100, size 100) s3 200.299 (offset 200, size 100) We have a noreturn function whose last instruction ends on the last byte of s2, so the saved return address is offset 200. Your change makes it so that when we say "is 200 contained within 100..199", we will say yes, it is. This gets us the correct Section for our symbol context and when we back up the pc value by one (the "decr_pc_and_recompute_addr_range = true" bit in RegisterContextLLDB::InitializeNonZerothFrame) so when we back up the offset within the section by 1, we're good. The current behavior is that we pick the wrong section (s3) and somehow backing up the pc isn't working. Maybe we can accomplish the same fix by looking at the if (decr_pc_and_recompute_addr_range) block of code? Is decr_pc_and_recompute_addr_range not being set for this case? Are we not correctly backing up the pc into the Section boundary correctly? I have access to a linux machine so I can play with this myself, but it will take me a while to set up lldb on that system, could you let me know if you looked at this approach? I know RegisterContextLLDB is complicated and it's easy to miss things - or it may be that you tried this approach and it didn't look possible. (and I haven't had to touch this code in a few years so I may have forgotten about some "new Section is the same as the old Section" sanity check or something in there... I don't see it right now, but I may have missed it.) https://reviews.llvm.org/D32022 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
