[Lldb-commits] [lldb] r267392 - Remove flaky decorator from two tests on linux
Author: labath
Date: Mon Apr 25 05:32:23 2016
New Revision: 267392
URL: http://llvm.org/viewvc/llvm-project?rev=267392&view=rev
Log:
Remove flaky decorator from two tests on linux
The flakyness is no longer reproducible, and the tests seem to be passing
reliably now.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/create_after_attach/TestCreateAfterAttach.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/create_after_attach/TestCreateAfterAttach.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/create_after_attach/TestCreateAfterAttach.py?rev=267392&r1=267391&r2=267392&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/create_after_attach/TestCreateAfterAttach.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/create_after_attach/TestCreateAfterAttach.py
Mon Apr 25 05:32:23 2016
@@ -30,7 +30,6 @@ class CreateAfterAttachTestCase(TestBase
# for FreeBSD.
@skipIfRemote
@skipIfWindows # Windows doesn't have fork.
-@expectedFlakeyLinux("llvm.org/pr16229") # 1/100 dosep, build 3546,
clang-3.5 x84_64
@skipIfiOSSimulator
def test_create_after_attach_with_fork(self):
"""Test thread creation after process attach."""
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py?rev=267392&r1=267391&r2=267392&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/exit_during_step/TestExitDuringStep.py
Mon Apr 25 05:32:23 2016
@@ -17,21 +17,18 @@ class ExitDuringStepTestCase(TestBase):
mydir = TestBase.compute_mydir(__file__)
@skipIfFreeBSD # llvm.org/pr21411: test is hanging
-@expectedFlakeyAndroid("llvm.org/pr26206")
def test(self):
"""Test thread exit during step handling."""
self.build(dictionary=self.getBuildFlags())
self.exit_during_step_base("thread step-inst -m all-threads", 'stop
reason = instruction step')
@skipIfFreeBSD # llvm.org/pr21411: test is hanging
-@expectedFlakeyAndroid("llvm.org/pr26206")
def test_step_over(self):
"""Test thread exit during step-over handling."""
self.build(dictionary=self.getBuildFlags())
self.exit_during_step_base("thread step-over -m all-threads", 'stop
reason = step over')
@skipIfFreeBSD # llvm.org/pr21411: test is hanging
-@expectedFlakeyAndroid("llvm.org/pr26206")
def test_step_in(self):
"""Test thread exit during step-in handling."""
self.build(dictionary=self.getBuildFlags())
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
tberghammer created this revision.
tberghammer added reviewers: labath, compnerd.
tberghammer added a subscriber: lldb-commits.
Herald added subscribers: srhines, danalbert, tberghammer, rengolin, aemerson.
Fix ARM attribute parsing for Android after rL267291
http://reviews.llvm.org/D19480
Files:
source/Core/ArchSpec.cpp
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1740,12 +1740,9 @@
{
DataExtractor data;
-if (sheader.sh_type != SHT_ARM_ATTRIBUTES)
-continue;
-if (section_size == 0 || set_data(data, sheader.sh_offset,
section_size) != section_size)
-continue;
-
-ParseARMAttributes(data, section_size, arch_spec);
+if (sheader.sh_type == SHT_ARM_ATTRIBUTES && section_size
!= 0 &&
+set_data(data, sheader.sh_offset, section_size) ==
section_size)
+ParseARMAttributes(data, section_size, arch_spec);
}
if (name == g_sect_name_gnu_debuglink)
Index: source/Core/ArchSpec.cpp
===
--- source/Core/ArchSpec.cpp
+++ source/Core/ArchSpec.cpp
@@ -1002,6 +1002,27 @@
return IsEqualTo (rhs, false);
}
+static bool
+isCompatibleEnvironment(llvm::Triple::EnvironmentType lhs,
llvm::Triple::EnvironmentType rhs)
+{
+if (lhs == rhs)
+return true;
+
+// If any of the environment is unknown then they are compatible
+if (lhs == llvm::Triple::UnknownEnvironment || rhs ==
llvm::Triple::UnknownEnvironment)
+return true;
+
+// If one of the environment is Android and the other one is EABI or
EABIHF then they are
+// considered to be compatible. This is required as a workaround for
shared libraries compiled
+// for Android without the NOTE section indicating that they are using the
Android ABI.
+if (lhs == llvm::Triple::Android && (rhs == llvm::Triple::EABI || rhs ==
llvm::Triple::EABIHF))
+return true;
+if (rhs == llvm::Triple::Android && (lhs == llvm::Triple::EABI || lhs ==
llvm::Triple::EABIHF))
+return true;
+
+return false;
+}
+
bool
ArchSpec::IsEqualTo (const ArchSpec& rhs, bool exact_match) const
{
@@ -1056,14 +1077,9 @@
const llvm::Triple::EnvironmentType lhs_triple_env =
lhs_triple.getEnvironment();
const llvm::Triple::EnvironmentType rhs_triple_env =
rhs_triple.getEnvironment();
-
-if (lhs_triple_env != rhs_triple_env)
-{
-// Only fail if both environment types are not unknown
-if (lhs_triple_env != llvm::Triple::UnknownEnvironment &&
-rhs_triple_env != llvm::Triple::UnknownEnvironment)
-return false;
-}
+
+if (!isCompatibleEnvironment(lhs_triple_env, rhs_triple_env))
+return false;
return true;
}
return false;
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1740,12 +1740,9 @@
{
DataExtractor data;
-if (sheader.sh_type != SHT_ARM_ATTRIBUTES)
-continue;
-if (section_size == 0 || set_data(data, sheader.sh_offset, section_size) != section_size)
-continue;
-
-ParseARMAttributes(data, section_size, arch_spec);
+if (sheader.sh_type == SHT_ARM_ATTRIBUTES && section_size != 0 &&
+set_data(data, sheader.sh_offset, section_size) == section_size)
+ParseARMAttributes(data, section_size, arch_spec);
}
if (name == g_sect_name_gnu_debuglink)
Index: source/Core/ArchSpec.cpp
===
--- source/Core/ArchSpec.cpp
+++ source/Core/ArchSpec.cpp
@@ -1002,6 +1002,27 @@
return IsEqualTo (rhs, false);
}
+static bool
+isCompatibleEnvironment(llvm::Triple::EnvironmentType lhs, llvm::Triple::EnvironmentType rhs)
+{
+if (lhs == rhs)
+return true;
+
+// If any of the environment is unknown then they are compatible
+if (lhs == llvm::Triple::UnknownEnvironment || rhs == llvm::Triple::UnknownEnvironment)
+return true;
+
+// If one of the environment is Android and the other one is EABI or EABIHF then they are
+// considered to be compatible. This is required as a workaround for shared libraries compiled
+// for Android without the NOTE
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
rengolin added inline comments. Comment at: source/Core/ArchSpec.cpp:1017 @@ +1016,3 @@ +// considered to be compatible. This is required as a workaround for shared libraries compiled +// for Android without the NOTE section indicating that they are using the Android ABI. +if (lhs == llvm::Triple::Android && (rhs == llvm::Triple::EABI || rhs == llvm::Triple::EABIHF)) Are you sure AndroidEabi and EabiHF are compatible? Android is always soft-float, is it not? http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
tberghammer added inline comments.
Comment at: source/Core/ArchSpec.cpp:1017
@@ +1016,3 @@
+// considered to be compatible. This is required as a workaround for
shared libraries compiled
+// for Android without the NOTE section indicating that they are using the
Android ABI.
+if (lhs == llvm::Triple::Android && (rhs == llvm::Triple::EABI || rhs ==
llvm::Triple::EABIHF))
rengolin wrote:
> Are you sure AndroidEabi and EabiHF are compatible? Android is always
> soft-float, is it not?
They are not always compatible but I don't see any way to detect it in the
current system and it is possible to have code compiled with AndroidEabi and
AndroidEabiHF inside the same application if all API crossing the ABI
boundaries are annotated with attribute((pcs("aapcs"))).
The android platform libraries are soft float with all API with floating point
argument is marked with attribute((pcs("aapcs"))) so user libraries can be hard
float (not sure how well it works)
http://reviews.llvm.org/D19480
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. Ideally, we'd be able to pick up the fact that we're dealing with an android shared library just from looking at it, but it seems they don't contain any information which would identify them as such. If anyone has a better solution, we'd like to hear about it. http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
rengolin added a comment. Don't Android libraries output build attributes for ARM? If they do, that's an easy way to know. http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r267405 - Handle invalid values of PLT entry size generated by linker
Author: omjavaid
Date: Mon Apr 25 08:45:39 2016
New Revision: 267405
URL: http://llvm.org/viewvc/llvm-project?rev=267405&view=rev
Log:
Handle invalid values of PLT entry size generated by linker
Make sure we figure out correct plt entry field in case linker has generated a
small value below realistic entry size like 4 bytes or below.
Differential revision: http://reviews.llvm.org/D19252
Modified:
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
Modified: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp?rev=267405&r1=267404&r2=267405&view=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp Mon Apr 25
08:45:39 2016
@@ -2610,7 +2610,10 @@ GetPltEntrySizeAndOffset(const ELFSectio
elf_xword plt_entsize = plt_hdr->sh_addralign ?
llvm::alignTo (plt_hdr->sh_entsize, plt_hdr->sh_addralign) :
plt_hdr->sh_entsize;
-if (plt_entsize == 0)
+// Some linkers e.g ld for arm, fill plt_hdr->sh_entsize field incorrectly.
+// PLT entries relocation code in general requires multiple instruction and
+// should be greater than 4 bytes in most cases. Try to guess correct size
just in case.
+if (plt_entsize <= 4)
{
// The linker haven't set the plt_hdr->sh_entsize field. Try to guess
the size of the plt
// entries based on the number of entries and the size of the plt
section with the
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19252: Handle invalid values of PLT entry size generated by ld + gcc on arm linux targets.
This revision was automatically updated to reflect the committed changes.
Closed by commit rL267405: Handle invalid values of PLT entry size generated by
linker (authored by omjavaid).
Changed prior to commit:
http://reviews.llvm.org/D19252?vs=54146&id=54845#toc
Repository:
rL LLVM
http://reviews.llvm.org/D19252
Files:
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
Index: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -2610,7 +2610,10 @@
elf_xword plt_entsize = plt_hdr->sh_addralign ?
llvm::alignTo (plt_hdr->sh_entsize, plt_hdr->sh_addralign) :
plt_hdr->sh_entsize;
-if (plt_entsize == 0)
+// Some linkers e.g ld for arm, fill plt_hdr->sh_entsize field incorrectly.
+// PLT entries relocation code in general requires multiple instruction and
+// should be greater than 4 bytes in most cases. Try to guess correct size
just in case.
+if (plt_entsize <= 4)
{
// The linker haven't set the plt_hdr->sh_entsize field. Try to guess
the size of the plt
// entries based on the number of entries and the size of the plt
section with the
Index: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -2610,7 +2610,10 @@
elf_xword plt_entsize = plt_hdr->sh_addralign ?
llvm::alignTo (plt_hdr->sh_entsize, plt_hdr->sh_addralign) : plt_hdr->sh_entsize;
-if (plt_entsize == 0)
+// Some linkers e.g ld for arm, fill plt_hdr->sh_entsize field incorrectly.
+// PLT entries relocation code in general requires multiple instruction and
+// should be greater than 4 bytes in most cases. Try to guess correct size just in case.
+if (plt_entsize <= 4)
{
// The linker haven't set the plt_hdr->sh_entsize field. Try to guess the size of the plt
// entries based on the number of entries and the size of the plt section with the
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
tberghammer added a comment. Both executables and shared libraries are containing ARM Attributes what contains the information about soft-float vs hard-float. I am not sure how accurate it is as in theory you can link together an object file compiled with soft float with a one compiled with hard float but most likely we can trust it to be good enough. The problem is that currently this information is not stored in the llvm::Triple so if the Environment part of the Triple is set to Android then the information is lost. I can try to recover the data from the architecture flags but I am not convinced that it is always possible and considering that the same executable can contain soft-float and hard-float code on Android we have to treat them as compatible architectures at some point. http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r267407 - Skip TestBitfileds on linux
Author: labath
Date: Mon Apr 25 09:00:23 2016
New Revision: 267407
URL: http://llvm.org/viewvc/llvm-project?rev=267407&view=rev
Log:
Skip TestBitfileds on linux
Test added in r267248 exposed a bug in handling of dwarf produced by
clang>=3.9, which causes a
crash during expression evaluation. Skip the test until this is sorted out.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py?rev=267407&r1=267406&r2=267407&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
Mon Apr 25 09:00:23 2016
@@ -21,6 +21,7 @@ class BitfieldsTestCase(TestBase):
self.line = line_number('main.c', '// Set break point at this line.')
@skipIfWindows # BitFields exhibit crashes in record layout on Windows
(http://llvm.org/pr21800)
+@skipIf("llvm.org/pr27510", oslist=["linux"], compiler="clang",
compiler_version=[">=", "3.9"]) # expectedFailure, skip to avoid crash
def test_and_run_command(self):
"""Test 'frame variable ...' on a variable with bitfields."""
self.build()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
rengolin added a comment. In http://reviews.llvm.org/D19480#410620, @tberghammer wrote: > Both executables and shared libraries are containing ARM Attributes what > contains the information about soft-float vs hard-float. I am not sure how > accurate it is as in theory you can link together an object file compiled > with soft float with a one compiled with hard float but most likely we can > trust it to be good enough. That's only true if one doesn't depend on the other, and only if you can guarantee that hard-float library functions will only be called using AAPCS_VFP and soft-float library functions will only be called with AAPCS. This is not the kind of guarantee one can do easily. Nor it is recommended that one does so. If Android applications can guarantee that by having two different ABIs for Android specific and user specific, this could work in theory. > The problem is that currently this information is not stored in the > llvm::Triple so if the Environment part of the Triple is set to Android then > the information is lost. I can try to recover the data from the architecture > flags but I am not convinced that it is always possible and considering that > the same executable can contain soft-float and hard-float code on Android we > have to treat them as compatible architectures at some point. The information is not lost, because "Android EABI" is always soft-float, and by definition, you should not be linking hard-float objects with soft-float ones. Can you elaborate which case you can reach that improbably scenario? cheers, --renato http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
srhines added a comment. In http://reviews.llvm.org/D19480#410641, @rengolin wrote: > In http://reviews.llvm.org/D19480#410620, @tberghammer wrote: > > > Both executables and shared libraries are containing ARM Attributes what > > contains the information about soft-float vs hard-float. I am not sure how > > accurate it is as in theory you can link together an object file compiled > > with soft float with a one compiled with hard float but most likely we can > > trust it to be good enough. > > > That's only true if one doesn't depend on the other, and only if you can > guarantee that hard-float library functions will only be called using > AAPCS_VFP and soft-float library functions will only be called with AAPCS. > > This is not the kind of guarantee one can do easily. Nor it is recommended > that one does so. If Android applications can guarantee that by having two > different ABIs for Android specific and user specific, this could work in > theory. > > > The problem is that currently this information is not stored in the > > llvm::Triple so if the Environment part of the Triple is set to Android > > then the information is lost. I can try to recover the data from the > > architecture flags but I am not convinced that it is always possible and > > considering that the same executable can contain soft-float and hard-float > > code on Android we have to treat them as compatible architectures at some > > point. > > > The information is not lost, because "Android EABI" is always soft-float, and > by definition, you should not be linking hard-float objects with soft-float > ones. > > Can you elaborate which case you can reach that improbably scenario? This happens because there is a broken mode (supported by an older NDK) that allowed for Hard FP calling conventions to be mixed with Soft FP in a hybrid mode. Everything in the user's application would get to use Hard FP, while any calls to bionic (libc/libm), or platform native libraries would use Soft FP. This wasn't really well tested, nor is it something that I think we should be promoting. Does this patch only affect debugging? Could we hold off on this until a long term decision is made about supporting mixed hard/soft FP calling conventions simultaneously? > cheers, > --renato http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
tberghammer added a comment. This patch only effects debugging (all modified file is part of LLDB). I want to get the Android <-> EABI part fixed ASAP as a recent LLDB change completely broke Android ARM debugging with adding ARM.Attributes support (causing Environment mismatch between EABI and Android when the executable contains an ".note.android.ident" while the shared library isn't). I can change the patch to check only for the Android <-> EABI case and we can wait with the hard-float part as almost nobody using hard-float if you think that is a better idea. http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
srhines added a comment. In http://reviews.llvm.org/D19480#410664, @tberghammer wrote: > This patch only effects debugging (all modified file is part of LLDB). > > I want to get the Android <-> EABI part fixed ASAP as a recent LLDB change > completely broke Android ARM debugging with adding ARM.Attributes support > (causing Environment mismatch between EABI and Android when the executable > contains an ".note.android.ident" while the shared library isn't). > > I can change the patch to check only for the Android <-> EABI case and we can > wait with the hard-float part as almost nobody using hard-float if you think > that is a better idea. I would prefer that this patch not address any of the Hard/Soft FP mismatch problem. If you can make it just fix the Android/EABI case you are looking at, that would be the best option. http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
tberghammer updated this revision to Diff 54854.
tberghammer added a comment.
I updated the diff to only address the soft-flat case (Android-EABI). This
fixes the most important case but I would like to fix the hard-flat case as
well in the not so distant future as we have the same problem (regression ) in
that case as well (combined with the hard/soft mismatch)
http://reviews.llvm.org/D19480
Files:
source/Core/ArchSpec.cpp
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1740,12 +1740,9 @@
{
DataExtractor data;
-if (sheader.sh_type != SHT_ARM_ATTRIBUTES)
-continue;
-if (section_size == 0 || set_data(data, sheader.sh_offset,
section_size) != section_size)
-continue;
-
-ParseARMAttributes(data, section_size, arch_spec);
+if (sheader.sh_type == SHT_ARM_ATTRIBUTES && section_size
!= 0 &&
+set_data(data, sheader.sh_offset, section_size) ==
section_size)
+ParseARMAttributes(data, section_size, arch_spec);
}
if (name == g_sect_name_gnu_debuglink)
Index: source/Core/ArchSpec.cpp
===
--- source/Core/ArchSpec.cpp
+++ source/Core/ArchSpec.cpp
@@ -1002,6 +1002,26 @@
return IsEqualTo (rhs, false);
}
+static bool
+isCompatibleEnvironment(llvm::Triple::EnvironmentType lhs,
llvm::Triple::EnvironmentType rhs)
+{
+if (lhs == rhs)
+return true;
+
+// If any of the environment is unknown then they are compatible
+if (lhs == llvm::Triple::UnknownEnvironment || rhs ==
llvm::Triple::UnknownEnvironment)
+return true;
+
+// If one of the environment is Android and the other one is EABI then
they are considered to
+// be compatible. This is required as a workaround for shared libraries
compiled for Android
+// without the NOTE section indicating that they are using the Android ABI.
+if ((lhs == llvm::Triple::Android && rhs == llvm::Triple::EABI) ||
+(rhs == llvm::Triple::Android && lhs == llvm::Triple::EABI))
+return true;
+
+return false;
+}
+
bool
ArchSpec::IsEqualTo (const ArchSpec& rhs, bool exact_match) const
{
@@ -1056,14 +1076,9 @@
const llvm::Triple::EnvironmentType lhs_triple_env =
lhs_triple.getEnvironment();
const llvm::Triple::EnvironmentType rhs_triple_env =
rhs_triple.getEnvironment();
-
-if (lhs_triple_env != rhs_triple_env)
-{
-// Only fail if both environment types are not unknown
-if (lhs_triple_env != llvm::Triple::UnknownEnvironment &&
-rhs_triple_env != llvm::Triple::UnknownEnvironment)
-return false;
-}
+
+if (!isCompatibleEnvironment(lhs_triple_env, rhs_triple_env))
+return false;
return true;
}
return false;
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1740,12 +1740,9 @@
{
DataExtractor data;
-if (sheader.sh_type != SHT_ARM_ATTRIBUTES)
-continue;
-if (section_size == 0 || set_data(data, sheader.sh_offset, section_size) != section_size)
-continue;
-
-ParseARMAttributes(data, section_size, arch_spec);
+if (sheader.sh_type == SHT_ARM_ATTRIBUTES && section_size != 0 &&
+set_data(data, sheader.sh_offset, section_size) == section_size)
+ParseARMAttributes(data, section_size, arch_spec);
}
if (name == g_sect_name_gnu_debuglink)
Index: source/Core/ArchSpec.cpp
===
--- source/Core/ArchSpec.cpp
+++ source/Core/ArchSpec.cpp
@@ -1002,6 +1002,26 @@
return IsEqualTo (rhs, false);
}
+static bool
+isCompatibleEnvironment(llvm::Triple::EnvironmentType lhs, llvm::Triple::EnvironmentType rhs)
+{
+if (lhs == rhs)
+return true;
+
+// If any of the environment is unknown then they are compatible
+if (lhs == llvm::Triple::UnknownEnvironment || rhs == llvm::Triple::UnknownEnvironment)
+return true;
+
+// If one of the environment is Android and the other one is EABI then they are considered to
+// be compatible. This is required as a workaround for shared libraries compiled for Android
+// without the
[Lldb-commits] [lldb] r267421 - skip TestBitfields.py on OS X
Author: tfiala
Date: Mon Apr 25 10:48:34 2016
New Revision: 267421
URL: http://llvm.org/viewvc/llvm-project?rev=267421&view=rev
Log:
skip TestBitfields.py on OS X
tracked by:
https://llvm.org/bugs/show_bug.cgi?id=27515
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py?rev=267421&r1=267420&r2=267421&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
Mon Apr 25 10:48:34 2016
@@ -22,6 +22,7 @@ class BitfieldsTestCase(TestBase):
@skipIfWindows # BitFields exhibit crashes in record layout on Windows
(http://llvm.org/pr21800)
@skipIf("llvm.org/pr27510", oslist=["linux"], compiler="clang",
compiler_version=[">=", "3.9"]) # expectedFailure, skip to avoid crash
+@skipIf("llvm.org/pr27515", oslist=["macosx"]) # Assertion failed: (Offset
>= Size), function insertPadding CGRecordLayoutBuilder.cpp
def test_and_run_command(self):
"""Test 'frame variable ...' on a variable with bitfields."""
self.build()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
This revision was automatically updated to reflect the committed changes.
Closed by commit rL267422: Fix ARM attribute parsing for Android after rL267291
(authored by tberghammer).
Changed prior to commit:
http://reviews.llvm.org/D19480?vs=54854&id=54864#toc
Repository:
rL LLVM
http://reviews.llvm.org/D19480
Files:
lldb/trunk/source/Core/ArchSpec.cpp
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
Index: lldb/trunk/source/Core/ArchSpec.cpp
===
--- lldb/trunk/source/Core/ArchSpec.cpp
+++ lldb/trunk/source/Core/ArchSpec.cpp
@@ -1002,6 +1002,26 @@
return IsEqualTo (rhs, false);
}
+static bool
+isCompatibleEnvironment(llvm::Triple::EnvironmentType lhs,
llvm::Triple::EnvironmentType rhs)
+{
+if (lhs == rhs)
+return true;
+
+// If any of the environment is unknown then they are compatible
+if (lhs == llvm::Triple::UnknownEnvironment || rhs ==
llvm::Triple::UnknownEnvironment)
+return true;
+
+// If one of the environment is Android and the other one is EABI then
they are considered to
+// be compatible. This is required as a workaround for shared libraries
compiled for Android
+// without the NOTE section indicating that they are using the Android ABI.
+if ((lhs == llvm::Triple::Android && rhs == llvm::Triple::EABI) ||
+(rhs == llvm::Triple::Android && lhs == llvm::Triple::EABI))
+return true;
+
+return false;
+}
+
bool
ArchSpec::IsEqualTo (const ArchSpec& rhs, bool exact_match) const
{
@@ -1056,14 +1076,9 @@
const llvm::Triple::EnvironmentType lhs_triple_env =
lhs_triple.getEnvironment();
const llvm::Triple::EnvironmentType rhs_triple_env =
rhs_triple.getEnvironment();
-
-if (lhs_triple_env != rhs_triple_env)
-{
-// Only fail if both environment types are not unknown
-if (lhs_triple_env != llvm::Triple::UnknownEnvironment &&
-rhs_triple_env != llvm::Triple::UnknownEnvironment)
-return false;
-}
+
+if (!isCompatibleEnvironment(lhs_triple_env, rhs_triple_env))
+return false;
return true;
}
return false;
Index: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1740,12 +1740,9 @@
{
DataExtractor data;
-if (sheader.sh_type != SHT_ARM_ATTRIBUTES)
-continue;
-if (section_size == 0 || set_data(data, sheader.sh_offset,
section_size) != section_size)
-continue;
-
-ParseARMAttributes(data, section_size, arch_spec);
+if (sheader.sh_type == SHT_ARM_ATTRIBUTES && section_size
!= 0 &&
+set_data(data, sheader.sh_offset, section_size) ==
section_size)
+ParseARMAttributes(data, section_size, arch_spec);
}
if (name == g_sect_name_gnu_debuglink)
Index: lldb/trunk/source/Core/ArchSpec.cpp
===
--- lldb/trunk/source/Core/ArchSpec.cpp
+++ lldb/trunk/source/Core/ArchSpec.cpp
@@ -1002,6 +1002,26 @@
return IsEqualTo (rhs, false);
}
+static bool
+isCompatibleEnvironment(llvm::Triple::EnvironmentType lhs, llvm::Triple::EnvironmentType rhs)
+{
+if (lhs == rhs)
+return true;
+
+// If any of the environment is unknown then they are compatible
+if (lhs == llvm::Triple::UnknownEnvironment || rhs == llvm::Triple::UnknownEnvironment)
+return true;
+
+// If one of the environment is Android and the other one is EABI then they are considered to
+// be compatible. This is required as a workaround for shared libraries compiled for Android
+// without the NOTE section indicating that they are using the Android ABI.
+if ((lhs == llvm::Triple::Android && rhs == llvm::Triple::EABI) ||
+(rhs == llvm::Triple::Android && lhs == llvm::Triple::EABI))
+return true;
+
+return false;
+}
+
bool
ArchSpec::IsEqualTo (const ArchSpec& rhs, bool exact_match) const
{
@@ -1056,14 +1076,9 @@
const llvm::Triple::EnvironmentType lhs_triple_env = lhs_triple.getEnvironment();
const llvm::Triple::EnvironmentType rhs_triple_env = rhs_triple.getEnvironment();
-
-if (lhs_triple_env != rhs_triple_env)
-{
-// Only fail if both environment types are not unknown
-if (lhs_triple_env != llvm::Triple::UnknownEnvironment &&
-rhs_triple_env != llvm::Triple::UnknownEnvironment)
-return false;
-}
+
+if (!isCompatibleEnvironment(lhs_triple_env, rhs_t
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
tberghammer added a comment. I committed in this change based on the approval from @labath with the Android - EABI support (no hard float) to get the LLDB Android ARM buildbots green again. If you have any more question comment then please let me know and I am happy to address them with a separate commit. Repository: rL LLVM http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r267422 - Fix ARM attribute parsing for Android after rL267291
Author: tberghammer
Date: Mon Apr 25 10:51:45 2016
New Revision: 267422
URL: http://llvm.org/viewvc/llvm-project?rev=267422&view=rev
Log:
Fix ARM attribute parsing for Android after rL267291
Differential revision: http://reviews.llvm.org/D19480
Modified:
lldb/trunk/source/Core/ArchSpec.cpp
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
Modified: lldb/trunk/source/Core/ArchSpec.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ArchSpec.cpp?rev=267422&r1=267421&r2=267422&view=diff
==
--- lldb/trunk/source/Core/ArchSpec.cpp (original)
+++ lldb/trunk/source/Core/ArchSpec.cpp Mon Apr 25 10:51:45 2016
@@ -1002,6 +1002,26 @@ ArchSpec::IsCompatibleMatch (const ArchS
return IsEqualTo (rhs, false);
}
+static bool
+isCompatibleEnvironment(llvm::Triple::EnvironmentType lhs,
llvm::Triple::EnvironmentType rhs)
+{
+if (lhs == rhs)
+return true;
+
+// If any of the environment is unknown then they are compatible
+if (lhs == llvm::Triple::UnknownEnvironment || rhs ==
llvm::Triple::UnknownEnvironment)
+return true;
+
+// If one of the environment is Android and the other one is EABI then
they are considered to
+// be compatible. This is required as a workaround for shared libraries
compiled for Android
+// without the NOTE section indicating that they are using the Android ABI.
+if ((lhs == llvm::Triple::Android && rhs == llvm::Triple::EABI) ||
+(rhs == llvm::Triple::Android && lhs == llvm::Triple::EABI))
+return true;
+
+return false;
+}
+
bool
ArchSpec::IsEqualTo (const ArchSpec& rhs, bool exact_match) const
{
@@ -1056,14 +1076,9 @@ ArchSpec::IsEqualTo (const ArchSpec& rhs
const llvm::Triple::EnvironmentType lhs_triple_env =
lhs_triple.getEnvironment();
const llvm::Triple::EnvironmentType rhs_triple_env =
rhs_triple.getEnvironment();
-
-if (lhs_triple_env != rhs_triple_env)
-{
-// Only fail if both environment types are not unknown
-if (lhs_triple_env != llvm::Triple::UnknownEnvironment &&
-rhs_triple_env != llvm::Triple::UnknownEnvironment)
-return false;
-}
+
+if (!isCompatibleEnvironment(lhs_triple_env, rhs_triple_env))
+return false;
return true;
}
return false;
Modified: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp?rev=267422&r1=267421&r2=267422&view=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp Mon Apr 25
10:51:45 2016
@@ -1740,12 +1740,9 @@ ObjectFileELF::GetSectionHeaderInfo(Sect
{
DataExtractor data;
-if (sheader.sh_type != SHT_ARM_ATTRIBUTES)
-continue;
-if (section_size == 0 || set_data(data, sheader.sh_offset,
section_size) != section_size)
-continue;
-
-ParseARMAttributes(data, section_size, arch_spec);
+if (sheader.sh_type == SHT_ARM_ATTRIBUTES && section_size
!= 0 &&
+set_data(data, sheader.sh_offset, section_size) ==
section_size)
+ParseARMAttributes(data, section_size, arch_spec);
}
if (name == g_sect_name_gnu_debuglink)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
rengolin added a comment. In http://reviews.llvm.org/D19480#410762, @tberghammer wrote: > I committed in this change based on the approval from @labath with the > Android - EABI support (no hard float) to get the LLDB Android ARM buildbots > green again. If you have any more question comment then please let me know > and I am happy to address them with a separate commit. Sounds good, thanks! Repository: rL LLVM http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19214: fix a race is the LLDB test suite results collection
amccarth added a subscriber: amccarth.
amccarth added a comment.
FYI: This patch seems to have broken all LLDB testing on Windows. I'll
investigate why.
Lots of the socket calls now result in stack traces like this:
Traceback (most recent call last):
File "C:\python_35\lib\multiprocessing\pool.py", line 119, in worker
result = (True, func(*args, **kwds))
File "C:\python_35\lib\multiprocessing\pool.py", line 44, in mapstar
return list(map(*args))
File "D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\dosep.py",
line 495, in process_dir_worker_multiprocessing_pool
return process_dir(*args)
File "D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\dosep.py",
line 442, in process_dir
command, timeout, base_name, inferior_pid_events, full_test_path))
File "D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\dosep.py",
line 417, in call_with_timeout
test_filename)
File "D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\dosep.py",
line 372, in send_inferior_post_run_events
send_events_to_collector(post_events, command)
File "D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\dosep.py",
line 308, in send_events_to_collector
formatter_spec = result_formatter.create_results_formatter(config)
File
"D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\result_formatter.py",
line 112, in create_results_formatter
results_file_object, cleanup_func = create_socket(config.port)
File
"D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\result_formatter.py",
line 78, in create_socket
sock.connect(("localhost", port))
ConnectionRefusedError: [WinError 10061] No connection could be made because
the target machine actively refused it
The changes to result_formatter.py are after the problematic line, so the root
cause it not immediately obvious. I have a guess that we're trying to open
more sockets than before and are therefore exceeding a handle limit imposed by
Python's use of ancient C RTL code.
http://reviews.llvm.org/D19214
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D19489: Use llvm_unreachable to quiet a VC++ compiler warning.
amccarth created this revision.
amccarth added a reviewer: spyffe.
amccarth added a subscriber: lldb-commits.
http://reviews.llvm.org/D19489
Files:
source/Expression/DiagnosticManager.cpp
Index: source/Expression/DiagnosticManager.cpp
===
--- source/Expression/DiagnosticManager.cpp
+++ source/Expression/DiagnosticManager.cpp
@@ -8,6 +8,9 @@
//===--===//
#include "lldb/Expression/DiagnosticManager.h"
+
+#include "llvm/Support/ErrorHandling.h"
+
#include "lldb/Core/Log.h"
#include "lldb/Core/StreamString.h"
@@ -45,6 +48,7 @@
case lldb_private::eDiagnosticSeverityRemark:
return "";
}
+llvm_unreachable("switch needs another case for DiagnosticSeverity enum");
}
std::string
Index: source/Expression/DiagnosticManager.cpp
===
--- source/Expression/DiagnosticManager.cpp
+++ source/Expression/DiagnosticManager.cpp
@@ -8,6 +8,9 @@
//===--===//
#include "lldb/Expression/DiagnosticManager.h"
+
+#include "llvm/Support/ErrorHandling.h"
+
#include "lldb/Core/Log.h"
#include "lldb/Core/StreamString.h"
@@ -45,6 +48,7 @@
case lldb_private::eDiagnosticSeverityRemark:
return "";
}
+llvm_unreachable("switch needs another case for DiagnosticSeverity enum");
}
std::string
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r267459 - Add missing qRegisterInfo option to gdbremote testcase
Author: fjricci Date: Mon Apr 25 15:24:30 2016 New Revision: 267459 URL: http://llvm.org/viewvc/llvm-project?rev=267459&view=rev Log: Add missing qRegisterInfo option to gdbremote testcase Summary: "gcc" is equivalent to "ehframe" in ProcessGDBRemote, but only "ehframe" was a valid response in the test suite. Reviewers: tfiala, jasonmolenda, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18807 Modified: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py Modified: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py?rev=267459&r1=267458&r2=267459&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py Mon Apr 25 15:24:30 2016 @@ -630,6 +630,7 @@ class GdbRemoteTestCaseBase(TestBase): "encoding", "format", "set", +"gcc", "ehframe", "dwarf", "generic", ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18807: Add missing qRegisterInfo option to gdbremote testcase
This revision was automatically updated to reflect the committed changes. Closed by commit rL267459: Add missing qRegisterInfo option to gdbremote testcase (authored by fjricci). Changed prior to commit: http://reviews.llvm.org/D18807?vs=52743&id=54892#toc Repository: rL LLVM http://reviews.llvm.org/D18807 Files: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py Index: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py === --- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py +++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py @@ -630,6 +630,7 @@ "encoding", "format", "set", +"gcc", "ehframe", "dwarf", "generic", Index: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py === --- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py +++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py @@ -630,6 +630,7 @@ "encoding", "format", "set", +"gcc", "ehframe", "dwarf", "generic", ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r267462 - Create _lldb python symlink correctly when LLVM_LIBDIR_SUFFIX is used
Author: fjricci
Date: Mon Apr 25 15:34:34 2016
New Revision: 267462
URL: http://llvm.org/viewvc/llvm-project?rev=267462&view=rev
Log:
Create _lldb python symlink correctly when LLVM_LIBDIR_SUFFIX is used
Summary:
Do not assume that liblldb.so is located in $(lldb -P)/../../../lib
when creating the _lldb python symlink. Instead, use the path passed
to LLVM_LIBDIR_SUFFIX, defaulting to $(lldb -P)/../../../lib when this
variable is not set.
Reviewers: vharron, emaste, zturner
Subscribers: zturner, labath, lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D19067
Modified:
lldb/trunk/CMakeLists.txt
lldb/trunk/scripts/Python/finishSwigPythonLLDB.py
lldb/trunk/scripts/finishSwigWrapperClasses.py
Modified: lldb/trunk/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=267462&r1=267461&r2=267462&view=diff
==
--- lldb/trunk/CMakeLists.txt (original)
+++ lldb/trunk/CMakeLists.txt Mon Apr 25 15:34:34 2016
@@ -31,7 +31,7 @@ add_subdirectory(lit)
if (NOT LLDB_DISABLE_PYTHON)
# Add a Post-Build Event to copy over Python files and create the symlink
to liblldb.so for the Python API(hardlink on Windows)
add_custom_target( finish_swig ALL
-COMMAND ${PYTHON_EXECUTABLE}
${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
"--srcRoot=${LLDB_SOURCE_DIR}"
"--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
"--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
"--prefix=${CMAKE_BINARY_DIR}" "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}"
-m
+COMMAND ${PYTHON_EXECUTABLE}
${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
"--srcRoot=${LLDB_SOURCE_DIR}"
"--targetDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
"--cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}/scripts"
"--prefix=${CMAKE_BINARY_DIR}" "--cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}"
"--lldbLibDir=lib${LLVM_LIBDIR_SUFFIX}" -m
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/scripts/lldb.py
COMMENT "Python script sym-linking LLDB Python API")
Modified: lldb/trunk/scripts/Python/finishSwigPythonLLDB.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/finishSwigPythonLLDB.py?rev=267462&r1=267461&r2=267462&view=diff
==
--- lldb/trunk/scripts/Python/finishSwigPythonLLDB.py (original)
+++ lldb/trunk/scripts/Python/finishSwigPythonLLDB.py Mon Apr 25 15:34:34 2016
@@ -358,11 +358,12 @@ def make_symlink(vDictArgs, vstrFramewor
# Args: vDictArgs - (R) Program input parameters.
# vstrFrameworkPythonDir - (R) Python framework directory.
# vstrLiblldbName - (R) File name for _lldb library.
+# vstrLiblldbDir - (R) liblldb directory.
# Returns: Bool - True = function success, False = failure.
# Str - Error description on task failure.
# Throws: None.
#--
-def make_symlink_liblldb(vDictArgs, vstrFrameworkPythonDir,
vstrLiblldbFileName):
+def make_symlink_liblldb(vDictArgs, vstrFrameworkPythonDir,
vstrLiblldbFileName, vstrLldbLibDir):
dbg = utilsDebug.CDebugFnVerbose("Python script make_symlink_liblldb()")
bOk = True
strErrMsg = ""
@@ -382,7 +383,7 @@ def make_symlink_liblldb(vDictArgs, vstr
bMakeFileCalled = "-m" in vDictArgs
if not bMakeFileCalled:
-strSrc = os.path.join("lib", "LLDB")
+strSrc = os.path.join(vstrLldbLibDir, "LLDB")
else:
strLibFileExtn = ""
if eOSType == utilsOsType.EnumOsType.Windows:
@@ -392,7 +393,7 @@ def make_symlink_liblldb(vDictArgs, vstr
strLibFileExtn = ".dylib"
else:
strLibFileExtn = ".so"
-strSrc = os.path.join("lib", "liblldb" + strLibFileExtn)
+strSrc = os.path.join(vstrLldbLibDir, "liblldb" + strLibFileExtn)
bOk, strErrMsg = make_symlink(vDictArgs, vstrFrameworkPythonDir, strSrc,
strTarget)
@@ -462,11 +463,12 @@ def make_symlink_lldb_argdumper(vDictArg
# the Python framework directory.
# Args: vDictArgs - (R) Program input parameters.
# vstrFrameworkPythonDir - (R) Python framework directory.
+# vstrLldbLibDir - (R) liblldb directory.
# Returns: Bool - True = function success, False = failure.
# strErrMsg - Error description on task failure.
# Throws: None.
#--
-def create_symlinks(vDictArgs, vstrFrameworkPythonDir):
+def create_symlinks(vDictArgs, vstrFrameworkPythonDir, vstrLldbLibDir):
dbg = utilsDebug.CDebugFnVerbose("Python script create_symlinks()")
bOk = True
strErrMsg = ""
@@ -477,7 +479,8 @@ def create_symlinks(vDictArgs, vstrFrame
if bOk:
bOk, strErrMsg = make_symlink_liblldb(vDictArgs,
vstrFrameworkPyt
Re: [Lldb-commits] [PATCH] D19067: Make sure to use lib instead of lib64 for LLDB_LIB_DIR
This revision was automatically updated to reflect the committed changes.
Closed by commit rL267462: Create _lldb python symlink correctly when
LLVM_LIBDIR_SUFFIX is used (authored by fjricci).
Changed prior to commit:
http://reviews.llvm.org/D19067?vs=54077&id=54894#toc
Repository:
rL LLVM
http://reviews.llvm.org/D19067
Files:
lldb/trunk/CMakeLists.txt
lldb/trunk/scripts/Python/finishSwigPythonLLDB.py
lldb/trunk/scripts/finishSwigWrapperClasses.py
Index: lldb/trunk/scripts/Python/finishSwigPythonLLDB.py
===
--- lldb/trunk/scripts/Python/finishSwigPythonLLDB.py
+++ lldb/trunk/scripts/Python/finishSwigPythonLLDB.py
@@ -358,11 +358,12 @@
# Args: vDictArgs - (R) Program input parameters.
# vstrFrameworkPythonDir - (R) Python framework directory.
# vstrLiblldbName - (R) File name for _lldb library.
+# vstrLiblldbDir - (R) liblldb directory.
# Returns: Bool - True = function success, False = failure.
# Str - Error description on task failure.
# Throws: None.
#--
-def make_symlink_liblldb(vDictArgs, vstrFrameworkPythonDir, vstrLiblldbFileName):
+def make_symlink_liblldb(vDictArgs, vstrFrameworkPythonDir, vstrLiblldbFileName, vstrLldbLibDir):
dbg = utilsDebug.CDebugFnVerbose("Python script make_symlink_liblldb()")
bOk = True
strErrMsg = ""
@@ -382,7 +383,7 @@
bMakeFileCalled = "-m" in vDictArgs
if not bMakeFileCalled:
-strSrc = os.path.join("lib", "LLDB")
+strSrc = os.path.join(vstrLldbLibDir, "LLDB")
else:
strLibFileExtn = ""
if eOSType == utilsOsType.EnumOsType.Windows:
@@ -392,7 +393,7 @@
strLibFileExtn = ".dylib"
else:
strLibFileExtn = ".so"
-strSrc = os.path.join("lib", "liblldb" + strLibFileExtn)
+strSrc = os.path.join(vstrLldbLibDir, "liblldb" + strLibFileExtn)
bOk, strErrMsg = make_symlink(vDictArgs, vstrFrameworkPythonDir, strSrc, strTarget)
@@ -462,11 +463,12 @@
# the Python framework directory.
# Args: vDictArgs - (R) Program input parameters.
# vstrFrameworkPythonDir - (R) Python framework directory.
+# vstrLldbLibDir - (R) liblldb directory.
# Returns: Bool - True = function success, False = failure.
# strErrMsg - Error description on task failure.
# Throws: None.
#--
-def create_symlinks(vDictArgs, vstrFrameworkPythonDir):
+def create_symlinks(vDictArgs, vstrFrameworkPythonDir, vstrLldbLibDir):
dbg = utilsDebug.CDebugFnVerbose("Python script create_symlinks()")
bOk = True
strErrMsg = ""
@@ -477,7 +479,8 @@
if bOk:
bOk, strErrMsg = make_symlink_liblldb(vDictArgs,
vstrFrameworkPythonDir,
- strLibLldbFileName)
+ strLibLldbFileName,
+ vstrLldbLibDir)
# Make symlink for darwin-debug on Darwin
strDarwinDebugFileName = "darwin-debug"
@@ -672,6 +675,28 @@
return (bOk, strWkDir, strErrMsg)
+#++---
+# Details: Retrieve the liblldb directory path, if it exists and is valid.
+# Args: vDictArgs - (R) Program input parameters.
+# Returns: Bool - True = function success, False = failure.
+# Str - liblldb directory path.
+# strErrMsg - Error description on task failure.
+# Throws: None.
+#--
+def get_liblldb_dir(vDictArgs):
+dbg = utilsDebug.CDebugFnVerbose("Python script get_liblldb_dir()")
+bOk = True
+strErrMsg = ""
+
+strLldbLibDir = ""
+bHaveLldbLibDir = "--lldbLibDir" in vDictArgs
+if bHaveLldbLibDir:
+strLldbLibDir = vDictArgs["--lldbLibDir"]
+if (bHaveLldbLibDir == False) or (strLldbLibDir.__len__() == 0):
+strLldbLibDir = "lib"
+
+return (bOk, strLldbLibDir, strErrMsg)
+
#-
#-
#-
@@ -697,6 +722,8 @@
be installed. Where non-Darwin systems want to put
the .py and .so files so that Python can find them
automatically. Python install directory.
+--lldbLibDirThe name of the directory containing liblldb.so.
+(optional) "lib" by default.
Results:0 Success
-100+ Error from this script to the caller script.
-100Error program failure with optional message.
@@ -727,10 +754,13 @@
print((strMsgConfigBuildDir % strCfgBldDir))
if bOk:
+
[Lldb-commits] [lldb] r267463 - Store absolute path for lldb executable in dotest.py
Author: fjricci
Date: Mon Apr 25 15:36:22 2016
New Revision: 267463
URL: http://llvm.org/viewvc/llvm-project?rev=267463&view=rev
Log:
Store absolute path for lldb executable in dotest.py
Summary:
lldb-server tests are currently being skipped on the
check-lldb target. This is because we get the path of
lldb-server by modifying the path to the lldb executable.
However, by this point, we've changed directories, and a
relative path to the build/bin directory will no longer point
to the location of lldb-server.
Storing an absolute path solves this issue.
Reviewers: vharron, zturner, tfiala, labath
Subscribers: labath, lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D19082
Modified:
lldb/trunk/packages/Python/lldbsuite/test/dotest.py
Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=267463&r1=267462&r2=267463&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Mon Apr 25 15:36:22 2016
@@ -307,7 +307,7 @@ def parseOptionsAndInitTestdirs():
configuration.lldbFrameworkPath = args.framework
if args.executable:
-lldbtest_config.lldbExec = args.executable
+lldbtest_config.lldbExec = os.path.realpath(args.executable)
if args.p:
if args.p.startswith('-'):
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19082: Store absolute path for lldb executable in dotest.py
This revision was automatically updated to reflect the committed changes.
Closed by commit rL267463: Store absolute path for lldb executable in dotest.py
(authored by fjricci).
Changed prior to commit:
http://reviews.llvm.org/D19082?vs=53637&id=54895#toc
Repository:
rL LLVM
http://reviews.llvm.org/D19082
Files:
lldb/trunk/packages/Python/lldbsuite/test/dotest.py
Index: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/dotest.py
+++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py
@@ -307,7 +307,7 @@
configuration.lldbFrameworkPath = args.framework
if args.executable:
-lldbtest_config.lldbExec = args.executable
+lldbtest_config.lldbExec = os.path.realpath(args.executable)
if args.p:
if args.p.startswith('-'):
Index: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/dotest.py
+++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py
@@ -307,7 +307,7 @@
configuration.lldbFrameworkPath = args.framework
if args.executable:
-lldbtest_config.lldbExec = args.executable
+lldbtest_config.lldbExec = os.path.realpath(args.executable)
if args.p:
if args.p.startswith('-'):
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r267466 - Use Process Plugin register indices when communicating with remote
Author: fjricci
Date: Mon Apr 25 15:59:11 2016
New Revision: 267466
URL: http://llvm.org/viewvc/llvm-project?rev=267466&view=rev
Log:
Use Process Plugin register indices when communicating with remote
Summary:
eRegisterKindProcessPlugin is used to store the register
indices used by the remote, and eRegisterKindLLDB is used
to store the internal lldb register indices. However, we're currently
using the lldb indices instead of the process plugin indices
when sending p/P packets. This will break if the remote uses
non-contiguous register indices.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D19305
Modified:
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
Modified:
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h?rev=267466&r1=267465&r2=267466&view=diff
==
--- lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
(original)
+++ lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
Mon Apr 25 15:59:11 2016
@@ -527,7 +527,7 @@ public:
bool
ReadRegister(lldb::tid_t tid,
- uint32_t reg_num,
+ uint32_t reg_num, // Must be the eRegisterKindProcessPlugin
register number, to be sent to the remote
StringExtractorGDBRemote &response);
bool
Modified:
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp?rev=267466&r1=267465&r2=267466&view=diff
==
--- lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
(original)
+++ lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
Mon Apr 25 15:59:11 2016
@@ -198,10 +198,11 @@ bool
GDBRemoteRegisterContext::GetPrimordialRegister(const RegisterInfo *reg_info,
GDBRemoteCommunicationClient
&gdb_comm)
{
-const uint32_t reg = reg_info->kinds[eRegisterKindLLDB];
+const uint32_t lldb_reg = reg_info->kinds[eRegisterKindLLDB];
+const uint32_t remote_reg = reg_info->kinds[eRegisterKindProcessPlugin];
StringExtractorGDBRemote response;
-if (gdb_comm.ReadRegister(m_thread.GetProtocolID(), reg, response))
-return PrivateSetRegisterValue (reg, response);
+if (gdb_comm.ReadRegister(m_thread.GetProtocolID(), remote_reg, response))
+return PrivateSetRegisterValue (lldb_reg, response);
return false;
}
@@ -316,7 +317,7 @@ GDBRemoteRegisterContext::SetPrimordialR
StreamString packet;
StringExtractorGDBRemote response;
const uint32_t reg = reg_info->kinds[eRegisterKindLLDB];
-packet.Printf ("P%x=", reg);
+packet.Printf ("P%x=", reg_info->kinds[eRegisterKindProcessPlugin]);
packet.PutBytesAsRawHex8 (m_reg_data.PeekData(reg_info->byte_offset,
reg_info->byte_size),
reg_info->byte_size,
endian::InlHostByteOrder(),
@@ -813,7 +814,7 @@ GDBRemoteRegisterContext::WriteAllRegist
if (restore_src)
{
StreamString packet;
-packet.Printf ("P%x=", reg);
+packet.Printf ("P%x=",
reg_info->kinds[eRegisterKindProcessPlugin]);
packet.PutBytesAsRawHex8 (restore_src,
reg_byte_size,
endian::InlHostByteOrder(),
@@ -836,7 +837,7 @@ GDBRemoteRegisterContext::WriteAllRegist
if (write_reg)
{
StreamString packet;
-packet.Printf ("P%x=", reg);
+packet.Printf ("P%x=",
reg_info->kinds[eRegisterKindProcessPlugin]);
packet.PutBytesAsRawHex8 (restore_src,
reg_byte_size,
endian::InlHostByteOrder(),
@@ -894,7 +895,7 @@ GDBRemoteRegisterContext::WriteAllRegist
continue;
}
StreamString packet;
-packet.Printf ("P%x=", reg_info->kinds[eRegisterKindLLDB]);
+packet.Printf ("P%x=",
reg_info->kinds[eRegisterKindProcessPlugin]);
pa
Re: [Lldb-commits] [PATCH] D19305: Use Process Plugin register indices when communicating with remote
This revision was automatically updated to reflect the committed changes.
Closed by commit rL267466: Use Process Plugin register indices when
communicating with remote (authored by fjricci).
Changed prior to commit:
http://reviews.llvm.org/D19305?vs=54303&id=54900#toc
Repository:
rL LLVM
http://reviews.llvm.org/D19305
Files:
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
Index: lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
===
--- lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -198,10 +198,11 @@
GDBRemoteRegisterContext::GetPrimordialRegister(const RegisterInfo *reg_info,
GDBRemoteCommunicationClient
&gdb_comm)
{
-const uint32_t reg = reg_info->kinds[eRegisterKindLLDB];
+const uint32_t lldb_reg = reg_info->kinds[eRegisterKindLLDB];
+const uint32_t remote_reg = reg_info->kinds[eRegisterKindProcessPlugin];
StringExtractorGDBRemote response;
-if (gdb_comm.ReadRegister(m_thread.GetProtocolID(), reg, response))
-return PrivateSetRegisterValue (reg, response);
+if (gdb_comm.ReadRegister(m_thread.GetProtocolID(), remote_reg, response))
+return PrivateSetRegisterValue (lldb_reg, response);
return false;
}
@@ -316,7 +317,7 @@
StreamString packet;
StringExtractorGDBRemote response;
const uint32_t reg = reg_info->kinds[eRegisterKindLLDB];
-packet.Printf ("P%x=", reg);
+packet.Printf ("P%x=", reg_info->kinds[eRegisterKindProcessPlugin]);
packet.PutBytesAsRawHex8 (m_reg_data.PeekData(reg_info->byte_offset,
reg_info->byte_size),
reg_info->byte_size,
endian::InlHostByteOrder(),
@@ -813,7 +814,7 @@
if (restore_src)
{
StreamString packet;
-packet.Printf ("P%x=", reg);
+packet.Printf ("P%x=",
reg_info->kinds[eRegisterKindProcessPlugin]);
packet.PutBytesAsRawHex8 (restore_src,
reg_byte_size,
endian::InlHostByteOrder(),
@@ -836,7 +837,7 @@
if (write_reg)
{
StreamString packet;
-packet.Printf ("P%x=", reg);
+packet.Printf ("P%x=",
reg_info->kinds[eRegisterKindProcessPlugin]);
packet.PutBytesAsRawHex8 (restore_src,
reg_byte_size,
endian::InlHostByteOrder(),
@@ -894,7 +895,7 @@
continue;
}
StreamString packet;
-packet.Printf ("P%x=", reg_info->kinds[eRegisterKindLLDB]);
+packet.Printf ("P%x=",
reg_info->kinds[eRegisterKindProcessPlugin]);
packet.PutBytesAsRawHex8 (data_sp->GetBytes() +
reg_info->byte_offset, reg_info->byte_size, endian::InlHostByteOrder(),
endian::InlHostByteOrder());
if (thread_suffix_supported)
packet.Printf (";thread:%4.4" PRIx64 ";",
m_thread.GetProtocolID());
Index:
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
===
--- lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
+++ lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
@@ -527,7 +527,7 @@
bool
ReadRegister(lldb::tid_t tid,
- uint32_t reg_num,
+ uint32_t reg_num, // Must be the eRegisterKindProcessPlugin
register number, to be sent to the remote
StringExtractorGDBRemote &response);
bool
Index: lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
===
--- lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -198,10 +198,11 @@
GDBRemoteRegisterContext::GetPrimordialRegister(const RegisterInfo *reg_info,
GDBRemoteCommunicationClient &gdb_comm)
{
-const uint32_t reg = reg_info->kinds[eRegisterKindLLDB];
+const uint32_t lldb_reg = reg_info->kinds[eRegisterKindLLDB];
+const uint32_t remote_re
Re: [Lldb-commits] [PATCH] D19305: Use Process Plugin register indices when communicating with remote
fjricci added a comment. Committed with comment added to ReadRegister declaration to specify that the argument is an eRegisterKindProcessPlugin register number Repository: rL LLVM http://reviews.llvm.org/D19305 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r267467 - Properly unload modules from target image list when using svr4 packets
Author: fjricci
Date: Mon Apr 25 16:02:24 2016
New Revision: 267467
URL: http://llvm.org/viewvc/llvm-project?rev=267467&view=rev
Log:
Properly unload modules from target image list when using svr4 packets
Summary:
When we receive an svr4 packet from the remote, we check for new modules
and add them to the list of images in the target. However, we did not
do the same for modules which have been removed.
This was causing TestLoadUnload to fail when using ds2, which uses
svr4 packets to communicate all library info on Linux. This patch fixes
the failing test.
Reviewers: zturner, tfiala, ADodds
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D19230
Modified:
lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Modified: lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp?rev=267467&r1=267466&r2=267467&view=diff
==
--- lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp (original)
+++ lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp Mon Apr
25 16:02:24 2016
@@ -4879,7 +4879,31 @@ ProcessGDBRemote::LoadModules (LoadedMod
if (new_modules.GetSize() > 0)
{
+ModuleList removed_modules;
Target &target = GetTarget();
+ModuleList &loaded_modules = m_process->GetTarget().GetImages();
+
+for (size_t i = 0; i < loaded_modules.GetSize(); ++i)
+{
+const lldb::ModuleSP loaded_module =
loaded_modules.GetModuleAtIndex(i);
+
+bool found = false;
+for (size_t j = 0; j < new_modules.GetSize(); ++j)
+{
+if (new_modules.GetModuleAtIndex(j).get() ==
loaded_module.get())
+found = true;
+}
+
+if (!found)
+{
+lldb_private::ObjectFile * obj = loaded_module->GetObjectFile
();
+if (obj && obj->GetType () !=
ObjectFile::Type::eTypeExecutable)
+removed_modules.Append (loaded_module);
+}
+}
+
+loaded_modules.Remove (removed_modules);
+m_process->GetTarget().ModulesDidUnload (removed_modules, false);
new_modules.ForEach ([&target](const lldb::ModuleSP module_sp) -> bool
{
@@ -4895,13 +4919,11 @@ ProcessGDBRemote::LoadModules (LoadedMod
return false;
});
-ModuleList &loaded_modules = m_process->GetTarget().GetImages();
loaded_modules.AppendIfNeeded (new_modules);
m_process->GetTarget().ModulesDidLoad (new_modules);
}
return new_modules.GetSize();
-
}
size_t
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19230: Properly unload modules from target image list when using svr4 packets
This revision was automatically updated to reflect the committed changes.
Closed by commit rL267467: Properly unload modules from target image list when
using svr4 packets (authored by fjricci).
Changed prior to commit:
http://reviews.llvm.org/D19230?vs=54083&id=54902#toc
Repository:
rL LLVM
http://reviews.llvm.org/D19230
Files:
lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Index: lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -4879,7 +4879,31 @@
if (new_modules.GetSize() > 0)
{
+ModuleList removed_modules;
Target &target = GetTarget();
+ModuleList &loaded_modules = m_process->GetTarget().GetImages();
+
+for (size_t i = 0; i < loaded_modules.GetSize(); ++i)
+{
+const lldb::ModuleSP loaded_module =
loaded_modules.GetModuleAtIndex(i);
+
+bool found = false;
+for (size_t j = 0; j < new_modules.GetSize(); ++j)
+{
+if (new_modules.GetModuleAtIndex(j).get() ==
loaded_module.get())
+found = true;
+}
+
+if (!found)
+{
+lldb_private::ObjectFile * obj = loaded_module->GetObjectFile
();
+if (obj && obj->GetType () !=
ObjectFile::Type::eTypeExecutable)
+removed_modules.Append (loaded_module);
+}
+}
+
+loaded_modules.Remove (removed_modules);
+m_process->GetTarget().ModulesDidUnload (removed_modules, false);
new_modules.ForEach ([&target](const lldb::ModuleSP module_sp) -> bool
{
@@ -4895,13 +4919,11 @@
return false;
});
-ModuleList &loaded_modules = m_process->GetTarget().GetImages();
loaded_modules.AppendIfNeeded (new_modules);
m_process->GetTarget().ModulesDidLoad (new_modules);
}
return new_modules.GetSize();
-
}
size_t
Index: lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -4879,7 +4879,31 @@
if (new_modules.GetSize() > 0)
{
+ModuleList removed_modules;
Target &target = GetTarget();
+ModuleList &loaded_modules = m_process->GetTarget().GetImages();
+
+for (size_t i = 0; i < loaded_modules.GetSize(); ++i)
+{
+const lldb::ModuleSP loaded_module = loaded_modules.GetModuleAtIndex(i);
+
+bool found = false;
+for (size_t j = 0; j < new_modules.GetSize(); ++j)
+{
+if (new_modules.GetModuleAtIndex(j).get() == loaded_module.get())
+found = true;
+}
+
+if (!found)
+{
+lldb_private::ObjectFile * obj = loaded_module->GetObjectFile ();
+if (obj && obj->GetType () != ObjectFile::Type::eTypeExecutable)
+removed_modules.Append (loaded_module);
+}
+}
+
+loaded_modules.Remove (removed_modules);
+m_process->GetTarget().ModulesDidUnload (removed_modules, false);
new_modules.ForEach ([&target](const lldb::ModuleSP module_sp) -> bool
{
@@ -4895,13 +4919,11 @@
return false;
});
-ModuleList &loaded_modules = m_process->GetTarget().GetImages();
loaded_modules.AppendIfNeeded (new_modules);
m_process->GetTarget().ModulesDidLoad (new_modules);
}
return new_modules.GetSize();
-
}
size_t
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r267468 - Maintain register numbering across xml include features
Author: fjricci
Date: Mon Apr 25 16:03:55 2016
New Revision: 267468
URL: http://llvm.org/viewvc/llvm-project?rev=267468&view=rev
Log:
Maintain register numbering across xml include features
Summary:
If the remote uses include features when communicating
xml register info back to lldb, the existing code would reset the
lldb register index at the beginning of each include node.
This would lead to multiple registers having the same lldb register index.
Since the lldb register numbers should be contiguous and unique,
maintain them accross the parsing of all of the xml feature nodes.
Reviewers: jingham, jasonmolenda, clayborg
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D19303
Modified:
lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Modified: lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp?rev=267468&r1=267467&r2=267468&view=diff
==
--- lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp (original)
+++ lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp Mon Apr
25 16:03:55 2016
@@ -4372,14 +4372,11 @@ struct GdbServerTargetInfo
};
bool
-ParseRegisters (XMLNode feature_node, GdbServerTargetInfo &target_info,
GDBRemoteDynamicRegisterInfo &dyn_reg_info, ABISP abi_sp)
+ParseRegisters (XMLNode feature_node, GdbServerTargetInfo &target_info,
GDBRemoteDynamicRegisterInfo &dyn_reg_info, ABISP abi_sp, uint32_t
&cur_reg_num, uint32_t ®_offset)
{
if (!feature_node)
return false;
-uint32_t cur_reg_num = 0;
-uint32_t reg_offset = 0;
-
feature_node.ForEachChildElementWithName("reg", [&target_info,
&dyn_reg_info, &cur_reg_num, ®_offset, &abi_sp](const XMLNode ®_node) ->
bool {
std::string gdb_group;
std::string gdb_type;
@@ -4635,12 +4632,16 @@ ProcessGDBRemote::GetGDBServerRegisterIn
return true; // Keep iterating through all children of the
target_node
});
+// Initialize these outside of ParseRegisters, since they should
not be reset inside each include feature
+uint32_t cur_reg_num = 0;
+uint32_t reg_offset = 0;
+
// Don't use Process::GetABI, this code gets called from
DidAttach, and in that context we haven't
// set the Target's architecture yet, so the ABI is also
potentially incorrect.
ABISP abi_to_use_sp = ABI::FindPlugin(arch_to_use);
if (feature_node)
{
-ParseRegisters(feature_node, target_info,
this->m_register_info, abi_to_use_sp);
+ParseRegisters(feature_node, target_info,
this->m_register_info, abi_to_use_sp, cur_reg_num, reg_offset);
}
for (const auto &include : target_info.includes)
@@ -4658,7 +4659,7 @@ ProcessGDBRemote::GetGDBServerRegisterIn
XMLNode include_feature_node =
include_xml_document.GetRootElement("feature");
if (include_feature_node)
{
-ParseRegisters(include_feature_node, target_info,
this->m_register_info, abi_to_use_sp);
+ParseRegisters(include_feature_node, target_info,
this->m_register_info, abi_to_use_sp, cur_reg_num, reg_offset);
}
}
this->m_register_info.Finalize(arch_to_use);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19303: Maintain register numbering across xml include features
This revision was automatically updated to reflect the committed changes.
Closed by commit rL267468: Maintain register numbering across xml include
features (authored by fjricci).
Changed prior to commit:
http://reviews.llvm.org/D19303?vs=54298&id=54904#toc
Repository:
rL LLVM
http://reviews.llvm.org/D19303
Files:
lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Index: lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -4372,14 +4372,11 @@
};
bool
-ParseRegisters (XMLNode feature_node, GdbServerTargetInfo &target_info,
GDBRemoteDynamicRegisterInfo &dyn_reg_info, ABISP abi_sp)
+ParseRegisters (XMLNode feature_node, GdbServerTargetInfo &target_info,
GDBRemoteDynamicRegisterInfo &dyn_reg_info, ABISP abi_sp, uint32_t
&cur_reg_num, uint32_t ®_offset)
{
if (!feature_node)
return false;
-uint32_t cur_reg_num = 0;
-uint32_t reg_offset = 0;
-
feature_node.ForEachChildElementWithName("reg", [&target_info,
&dyn_reg_info, &cur_reg_num, ®_offset, &abi_sp](const XMLNode ®_node) ->
bool {
std::string gdb_group;
std::string gdb_type;
@@ -4635,12 +4632,16 @@
return true; // Keep iterating through all children of the
target_node
});
+// Initialize these outside of ParseRegisters, since they should
not be reset inside each include feature
+uint32_t cur_reg_num = 0;
+uint32_t reg_offset = 0;
+
// Don't use Process::GetABI, this code gets called from
DidAttach, and in that context we haven't
// set the Target's architecture yet, so the ABI is also
potentially incorrect.
ABISP abi_to_use_sp = ABI::FindPlugin(arch_to_use);
if (feature_node)
{
-ParseRegisters(feature_node, target_info,
this->m_register_info, abi_to_use_sp);
+ParseRegisters(feature_node, target_info,
this->m_register_info, abi_to_use_sp, cur_reg_num, reg_offset);
}
for (const auto &include : target_info.includes)
@@ -4658,7 +4659,7 @@
XMLNode include_feature_node =
include_xml_document.GetRootElement("feature");
if (include_feature_node)
{
-ParseRegisters(include_feature_node, target_info,
this->m_register_info, abi_to_use_sp);
+ParseRegisters(include_feature_node, target_info,
this->m_register_info, abi_to_use_sp, cur_reg_num, reg_offset);
}
}
this->m_register_info.Finalize(arch_to_use);
Index: lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -4372,14 +4372,11 @@
};
bool
-ParseRegisters (XMLNode feature_node, GdbServerTargetInfo &target_info, GDBRemoteDynamicRegisterInfo &dyn_reg_info, ABISP abi_sp)
+ParseRegisters (XMLNode feature_node, GdbServerTargetInfo &target_info, GDBRemoteDynamicRegisterInfo &dyn_reg_info, ABISP abi_sp, uint32_t &cur_reg_num, uint32_t ®_offset)
{
if (!feature_node)
return false;
-uint32_t cur_reg_num = 0;
-uint32_t reg_offset = 0;
-
feature_node.ForEachChildElementWithName("reg", [&target_info, &dyn_reg_info, &cur_reg_num, ®_offset, &abi_sp](const XMLNode ®_node) -> bool {
std::string gdb_group;
std::string gdb_type;
@@ -4635,12 +4632,16 @@
return true; // Keep iterating through all children of the target_node
});
+// Initialize these outside of ParseRegisters, since they should not be reset inside each include feature
+uint32_t cur_reg_num = 0;
+uint32_t reg_offset = 0;
+
// Don't use Process::GetABI, this code gets called from DidAttach, and in that context we haven't
// set the Target's architecture yet, so the ABI is also potentially incorrect.
ABISP abi_to_use_sp = ABI::FindPlugin(arch_to_use);
if (feature_node)
{
-ParseRegisters(feature_node, target_info, this->m_register_info, abi_to_use_sp);
+ParseRegisters(feature_node, target_info, this->m_register_info, abi_to_use_sp, cur_reg_num, reg_offset);
}
for (const auto &include : target_info.includes)
@@ -4658,7 +4659,7 @@
XMLNode include_feature_node = include_xml_document.GetRootElement("feature");
if (include_feature_node)
{
-ParseRegisters(include_feature_node, target_info, this->m_register_info, abi_to_use_sp)
Re: [Lldb-commits] [PATCH] D19214: fix a race is the LLDB test suite results collection
tfiala added a comment. My guess here would be that the fixing of the race - i.e. ensuring the listening side is up and running before allowing the sender to continue, is probably keeping more sockets open than before (i.e. fixing the race, but doing so by using an average larger number of resources). There are at least a couple ways to solve that, if that indeed is the issue: 1. Don't run as many threads on Windows (set --threads 24 or 32), 2. We abstract the communication mechanism, and use something different on Windows and/or something better for all, that allows bi-directional communication and isn't as limited. The "something different" could be a file based approach or some kind of other IPC mechanism. The key is it needs to be compatible with the asyncore approach used as part of the main loop in dosep.py. What you probably don't want to do is revert this on Windows, since it is likely ensuring some test events come in that were getting dropped before. If you end up getting excessively stuck on this, I'd suggest doing #1 to eliminate the limit from being hit, while a better solution for #2 is worked out for Windows. (And if you get stuck on #2, let me know, I may be able to dig around a bit and help, or at least get a test suite for that part up so you can plug in an implementation that works). http://reviews.llvm.org/D19214 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19082: Store absolute path for lldb executable in dotest.py
tfiala added a comment. Didn't get to it in time, but yes this looks fine. Repository: rL LLVM http://reviews.llvm.org/D19082 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r267443 - test commit
Author: fjricci Date: Mon Apr 25 14:02:05 2016 New Revision: 267443 URL: http://llvm.org/viewvc/llvm-project?rev=267443&view=rev Log: test commit Modified: lldb/trunk/docs/lldb-for-gdb-users.txt Modified: lldb/trunk/docs/lldb-for-gdb-users.txt URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/lldb-for-gdb-users.txt?rev=267443&r1=267442&r2=267443&view=diff == --- lldb/trunk/docs/lldb-for-gdb-users.txt (original) +++ lldb/trunk/docs/lldb-for-gdb-users.txt Mon Apr 25 14:02:05 2016 @@ -222,7 +222,7 @@ Or you can attach to a process by name w (lldb) process attach -n Sketch -the "attach by name" also supports the "-w" option which waits for the +The "attach by name" also supports the "-w" option which waits for the next process of that name to show up, and attaches to that. You can also attach by PID: ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19214: fix a race is the LLDB test suite results collection
amccarth added a comment. We already limit threads on Windows to work around other problems. Technically, we force Windows to always use the multiprocessing-pool instead of the threading-pool, which I think has the effect of limiting the number of threads. I suspect that the first several invocations are stuck waiting "forever" for the new ACK byte (perhaps because of buffering?) and that causes the rest of the invocations to fail. I'm still investigating. Having been broken for a week, it seems we've already collected 30-40 newly broken tests on Windows. :-( http://reviews.llvm.org/D19214 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19214: fix a race is the LLDB test suite results collection
tfiala added a comment. Ick. Yeah that sounds like something to resolve quickly. They shouldn't be getting stuck. That would imply that the side running via dosep.py (the listener socket) is either (1) no longer running and therefore the listener isn't spinning up, although that would be catastrophic and nothing else would work, or (2) the listening socket that fires up isn't getting time or is for some other reason not getting its send out. Can you dial down the threads (which in the Windows case then means processes) further? How low are they set to now? http://reviews.llvm.org/D19214 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r267478 - Fix StackFrame::GetVariables(...) function that was broken by 261858 when lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables(...
Author: gclayton Date: Mon Apr 25 16:54:10 2016 New Revision: 267478 URL: http://llvm.org/viewvc/llvm-project?rev=267478&view=rev Log: Fix StackFrame::GetVariables(...) function that was broken by 261858 when lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables(...) function should get all variables regardless if they are in scope. This wasn't caught by the test suite so I added a test for it. Added: lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/ lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c Modified: lldb/trunk/source/Target/StackFrame.cpp Added: lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile?rev=267478&view=auto == --- lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile (added) +++ lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile Mon Apr 25 16:54:10 2016 @@ -0,0 +1,5 @@ +LEVEL = ../../../make + +C_SOURCES := main.c + +include $(LEVEL)/Makefile.rules Added: lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py?rev=267478&view=auto == --- lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py (added) +++ lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py Mon Apr 25 16:54:10 2016 @@ -0,0 +1,190 @@ +""" +Test that SBFrame::GetVariables() calls work correctly. +""" + +from __future__ import print_function + + + +import os, time +import lldb +from lldbsuite.test.decorators import * +from lldbsuite.test.lldbtest import * +from lldbsuite.test import lldbplatform +from lldbsuite.test import lldbutil + +def get_names_from_value_list(value_list): +names = list() +for value in value_list: +names.append(value.GetName()) +return names + +class TestGetVariables(TestBase): + +mydir = TestBase.compute_mydir(__file__) + +def setUp(self): +# Call super's setUp(). +TestBase.setUp(self) +self.source = 'main.c' + +def verify_variable_names(self, description, value_list, names): +copy_names = list(names) +actual_names = get_names_from_value_list(value_list) +for name in actual_names: +if name in copy_names: +copy_names.remove(name) +else: +self.assertTrue(False, "didn't find '%s' in %s" % (name, copy_names)) +self.assertEqual(len(copy_names), 0, "%s: we didn't find variables: %s in value list (%s)" % (description, copy_names, actual_names)) + +def test (self): +self.build () + +# Set debugger into synchronous mode +self.dbg.SetAsync(False) + +# Create a target by the debugger. +exe = os.path.join(os.getcwd(), "a.out") +target = self.dbg.CreateTarget(exe) +self.assertTrue(target, VALID_TARGET) + +line1 = line_number(self.source, '// breakpoint 1') +line2 = line_number(self.source, '// breakpoint 2') +line3 = line_number(self.source, '// breakpoint 3') + +breakpoint1 = target.BreakpointCreateByLocation (self.source, line1); +breakpoint2 = target.BreakpointCreateByLocation (self.source, line2); +breakpoint3 = target.BreakpointCreateByLocation (self.source, line3); + +self.assertTrue(breakpoint1.GetNumLocations() >= 1, PROCESS_IS_VALID) +self.assertTrue(breakpoint2.GetNumLocations() >= 1, PROCESS_IS_VALID) +self.assertTrue(breakpoint3.GetNumLocations() >= 1, PROCESS_IS_VALID) + +# Register our shared libraries for remote targets so they get automatically uploaded +arguments = None +environment = None + +# Now launch the process, and do not stop at entry point. +process = target.LaunchSimple (arguments, environment, self.get_process_working_directory()) +self.assertTrue(process, PROCESS_IS_VALID) + +threads = lldbutil.get_threads_stopped_at_breakpoint (process, breakpoint1) +self.assertEqual(len(threads), 1, "There should be a thread stopped at breakpoint 1") + +thread = threads[0] +self.assertTrue(thread.IsValid(), "Thread must be v
Re: [Lldb-commits] [lldb] r267478 - Fix StackFrame::GetVariables(...) function that was broken by 261858 when lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables
Is g_global_var necessarily static? On Linux, we're only seeing 2 static variables when your test expects 3. > static_names = ['static_var', 'g_global_var', 'static_var'] I'm guessing g_global_var isn't treated as static. On Mon, Apr 25, 2016 at 2:54 PM, Greg Clayton via lldb-commits < lldb-commits@lists.llvm.org> wrote: > Author: gclayton > Date: Mon Apr 25 16:54:10 2016 > New Revision: 267478 > > URL: http://llvm.org/viewvc/llvm-project?rev=267478&view=rev > Log: > Fix StackFrame::GetVariables(...) function that was broken by 261858 when > lambda functions were added to Block::AppendBlockVariables(). The > Stackframe::GetVariables(...) function should get all variables regardless > if they are in scope. > > This wasn't caught by the test suite so I added a test for it. > > > Added: > > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/ > > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c > Modified: > lldb/trunk/source/Target/StackFrame.cpp > > Added: > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > URL: > http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile?rev=267478&view=auto > > == > --- > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > (added) > +++ > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > Mon Apr 25 16:54:10 2016 > @@ -0,0 +1,5 @@ > +LEVEL = ../../../make > + > +C_SOURCES := main.c > + > +include $(LEVEL)/Makefile.rules > > Added: > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > URL: > http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py?rev=267478&view=auto > > == > --- > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > (added) > +++ > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > Mon Apr 25 16:54:10 2016 > @@ -0,0 +1,190 @@ > +""" > +Test that SBFrame::GetVariables() calls work correctly. > +""" > + > +from __future__ import print_function > + > + > + > +import os, time > +import lldb > +from lldbsuite.test.decorators import * > +from lldbsuite.test.lldbtest import * > +from lldbsuite.test import lldbplatform > +from lldbsuite.test import lldbutil > + > +def get_names_from_value_list(value_list): > +names = list() > +for value in value_list: > +names.append(value.GetName()) > +return names > + > +class TestGetVariables(TestBase): > + > +mydir = TestBase.compute_mydir(__file__) > + > +def setUp(self): > +# Call super's setUp(). > +TestBase.setUp(self) > +self.source = 'main.c' > + > +def verify_variable_names(self, description, value_list, names): > +copy_names = list(names) > +actual_names = get_names_from_value_list(value_list) > +for name in actual_names: > +if name in copy_names: > +copy_names.remove(name) > +else: > +self.assertTrue(False, "didn't find '%s' in %s" % (name, > copy_names)) > +self.assertEqual(len(copy_names), 0, "%s: we didn't find > variables: %s in value list (%s)" % (description, copy_names, actual_names)) > + > +def test (self): > +self.build () > + > +# Set debugger into synchronous mode > +self.dbg.SetAsync(False) > + > +# Create a target by the debugger. > +exe = os.path.join(os.getcwd(), "a.out") > +target = self.dbg.CreateTarget(exe) > +self.assertTrue(target, VALID_TARGET) > + > +line1 = line_number(self.source, '// breakpoint 1') > +line2 = line_number(self.source, '// breakpoint 2') > +line3 = line_number(self.source, '// breakpoint 3') > + > +breakpoint1 = target.BreakpointCreateByLocation (self.source, > line1); > +breakpoint2 = target.BreakpointCreateByLocation (self.source, > line2); > +breakpoint3 = target.BreakpointCreateByLocation (self.source, > line3); > + > +self.assertTrue(breakpoint1.GetNumLocations() >= 1, > PROCESS_IS_VALID) > +self.assertTrue(breakpoint2.GetNumLocations() >= 1, > PROCESS_IS_VALID) > +self.assertTrue(breakpoint3.GetNumLocations() >= 1, > PROCESS_IS_VALID) > + > +# Register our shared libraries for remote targets so they get > automatically uploaded > +arguments = None > +environment = None > + > +# Now launch the process, and do not stop at entry p
Re: [Lldb-commits] [lldb] r267478 - Fix StackFrame::GetVariables(...) function that was broken by 261858 when lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables
AFAICT, happens only with Clang; Using g_static_var, say as "return g_static_var - 123;", fixes for me. On Mon, Apr 25, 2016 at 3:50 PM, Chaoren Lin via lldb-commits wrote: > Is g_global_var necessarily static? > > On Linux, we're only seeing 2 static variables when your test expects 3. > >> static_names = ['static_var', 'g_global_var', 'static_var'] > > I'm guessing g_global_var isn't treated as static. > > On Mon, Apr 25, 2016 at 2:54 PM, Greg Clayton via lldb-commits > wrote: >> >> Author: gclayton >> Date: Mon Apr 25 16:54:10 2016 >> New Revision: 267478 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=267478&view=rev >> Log: >> Fix StackFrame::GetVariables(...) function that was broken by 261858 when >> lambda functions were added to Block::AppendBlockVariables(). The >> Stackframe::GetVariables(...) function should get all variables regardless >> if they are in scope. >> >> This wasn't caught by the test suite so I added a test for it. >> >> >> Added: >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/ >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c >> Modified: >> lldb/trunk/source/Target/StackFrame.cpp >> >> Added: >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile >> URL: >> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile?rev=267478&view=auto >> >> == >> --- >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile >> (added) >> +++ >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile >> Mon Apr 25 16:54:10 2016 >> @@ -0,0 +1,5 @@ >> +LEVEL = ../../../make >> + >> +C_SOURCES := main.c >> + >> +include $(LEVEL)/Makefile.rules >> >> Added: >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py >> URL: >> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py?rev=267478&view=auto >> >> == >> --- >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py >> (added) >> +++ >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py >> Mon Apr 25 16:54:10 2016 >> @@ -0,0 +1,190 @@ >> +""" >> +Test that SBFrame::GetVariables() calls work correctly. >> +""" >> + >> +from __future__ import print_function >> + >> + >> + >> +import os, time >> +import lldb >> +from lldbsuite.test.decorators import * >> +from lldbsuite.test.lldbtest import * >> +from lldbsuite.test import lldbplatform >> +from lldbsuite.test import lldbutil >> + >> +def get_names_from_value_list(value_list): >> +names = list() >> +for value in value_list: >> +names.append(value.GetName()) >> +return names >> + >> +class TestGetVariables(TestBase): >> + >> +mydir = TestBase.compute_mydir(__file__) >> + >> +def setUp(self): >> +# Call super's setUp(). >> +TestBase.setUp(self) >> +self.source = 'main.c' >> + >> +def verify_variable_names(self, description, value_list, names): >> +copy_names = list(names) >> +actual_names = get_names_from_value_list(value_list) >> +for name in actual_names: >> +if name in copy_names: >> +copy_names.remove(name) >> +else: >> +self.assertTrue(False, "didn't find '%s' in %s" % (name, >> copy_names)) >> +self.assertEqual(len(copy_names), 0, "%s: we didn't find >> variables: %s in value list (%s)" % (description, copy_names, actual_names)) >> + >> +def test (self): >> +self.build () >> + >> +# Set debugger into synchronous mode >> +self.dbg.SetAsync(False) >> + >> +# Create a target by the debugger. >> +exe = os.path.join(os.getcwd(), "a.out") >> +target = self.dbg.CreateTarget(exe) >> +self.assertTrue(target, VALID_TARGET) >> + >> +line1 = line_number(self.source, '// breakpoint 1') >> +line2 = line_number(self.source, '// breakpoint 2') >> +line3 = line_number(self.source, '// breakpoint 3') >> + >> +breakpoint1 = target.BreakpointCreateByLocation (self.source, >> line1); >> +breakpoint2 = target.BreakpointCreateByLocation (self.source, >> line2); >> +breakpoint3 = target.BreakpointCreateByLocation (self.source, >> line3); >> + >> +self.assertTrue(breakpoint1.GetNumLocations() >= 1, >> PROCESS_IS_VALID) >> +self.assertTrue(breakpoint2.GetNumLocations() >= 1, >> PROCESS_IS_VALID) >> +self.assert
Re: [Lldb-commits] [PATCH] D19214: fix a race is the LLDB test suite results collection
amccarth added a comment. I got it. There was an exception being thrown from asyncore so early that it didn't give a proper stack trace. The problem boils down to Python 3 drawing a distinction between strings and bytearrays. Patch to come momentarily. Thanks for your help. http://reviews.llvm.org/D19214 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D19510: Fix send and receive of ACK byte in test infrastructure for Python 3.5
amccarth created this revision.
amccarth added a reviewer: tfiala.
amccarth added a subscriber: lldb-commits.
Python 3.5 is pickier about the distinction between chars and bytes (and
strings and bytearrays) than Python 2.7.
The call to ack_bytes.append(chr(42)) was causing a type error to be thrown
(during init, so we didn't see a proper stack trace).
I've used the b'*' syntax which creates a bytearray in Python 3 and a plain
string in Python 2. I believe this should work in Python 2, but I'm not in a
position to test that. If you want to try patching this in to your build to be
sure, it would be appreciated.
http://reviews.llvm.org/D19510
Files:
packages/Python/lldbsuite/test_event/dotest_channels.py
packages/Python/lldbsuite/test_event/formatter/__init__.py
Index: packages/Python/lldbsuite/test_event/formatter/__init__.py
===
--- packages/Python/lldbsuite/test_event/formatter/__init__.py
+++ packages/Python/lldbsuite/test_event/formatter/__init__.py
@@ -40,9 +40,6 @@
self.cleanup_func = cleanup_func
-SOCKET_ACK_BYTE_VALUE = b'*' # ASCII for chr(42)
-
-
def create_results_formatter(config):
"""Sets up a test results formatter.
@@ -78,7 +75,7 @@
# listener socket gets spun up; otherwise,
# we lose the test result info.
read_bytes = sock.recv(1)
-if read_bytes is None or (len(read_bytes) < 1) or (read_bytes[0] !=
SOCKET_ACK_BYTE_VALUE):
+if read_bytes is None or (len(read_bytes) < 1) or (read_bytes != b'*'):
raise Exception("listening socket did not respond with ack byte:
response={}".format(read_bytes))
return sock, lambda: socket_closer(sock)
Index: packages/Python/lldbsuite/test_event/dotest_channels.py
===
--- packages/Python/lldbsuite/test_event/dotest_channels.py
+++ packages/Python/lldbsuite/test_event/dotest_channels.py
@@ -59,8 +59,7 @@
# the initiators of the socket to await this to ensure
# that this end is up and running (and therefore already
# into the async map).
-ack_bytes = bytearray()
-ack_bytes.append(chr(42))
+ack_bytes = b'*'
file_object.send(ack_bytes)
def deserialize_payload(self):
Index: packages/Python/lldbsuite/test_event/formatter/__init__.py
===
--- packages/Python/lldbsuite/test_event/formatter/__init__.py
+++ packages/Python/lldbsuite/test_event/formatter/__init__.py
@@ -40,9 +40,6 @@
self.cleanup_func = cleanup_func
-SOCKET_ACK_BYTE_VALUE = b'*' # ASCII for chr(42)
-
-
def create_results_formatter(config):
"""Sets up a test results formatter.
@@ -78,7 +75,7 @@
# listener socket gets spun up; otherwise,
# we lose the test result info.
read_bytes = sock.recv(1)
-if read_bytes is None or (len(read_bytes) < 1) or (read_bytes[0] != SOCKET_ACK_BYTE_VALUE):
+if read_bytes is None or (len(read_bytes) < 1) or (read_bytes != b'*'):
raise Exception("listening socket did not respond with ack byte: response={}".format(read_bytes))
return sock, lambda: socket_closer(sock)
Index: packages/Python/lldbsuite/test_event/dotest_channels.py
===
--- packages/Python/lldbsuite/test_event/dotest_channels.py
+++ packages/Python/lldbsuite/test_event/dotest_channels.py
@@ -59,8 +59,7 @@
# the initiators of the socket to await this to ensure
# that this end is up and running (and therefore already
# into the async map).
-ack_bytes = bytearray()
-ack_bytes.append(chr(42))
+ack_bytes = b'*'
file_object.send(ack_bytes)
def deserialize_payload(self):
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r267478 - Fix StackFrame::GetVariables(...) function that was broken by 261858 when lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables
Ah, I see. Is that a known clang bug? On Mon, Apr 25, 2016 at 4:07 PM, Siva Chandra wrote: > AFAICT, happens only with Clang; Using g_static_var, say as "return > g_static_var - 123;", fixes for me. > > On Mon, Apr 25, 2016 at 3:50 PM, Chaoren Lin via lldb-commits > wrote: > > Is g_global_var necessarily static? > > > > On Linux, we're only seeing 2 static variables when your test expects 3. > > > >> static_names = ['static_var', 'g_global_var', 'static_var'] > > > > I'm guessing g_global_var isn't treated as static. > > > > On Mon, Apr 25, 2016 at 2:54 PM, Greg Clayton via lldb-commits > > wrote: > >> > >> Author: gclayton > >> Date: Mon Apr 25 16:54:10 2016 > >> New Revision: 267478 > >> > >> URL: http://llvm.org/viewvc/llvm-project?rev=267478&view=rev > >> Log: > >> Fix StackFrame::GetVariables(...) function that was broken by 261858 > when > >> lambda functions were added to Block::AppendBlockVariables(). The > >> Stackframe::GetVariables(...) function should get all variables > regardless > >> if they are in scope. > >> > >> This wasn't caught by the test suite so I added a test for it. > >> > >> > >> Added: > >> > >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/ > >> > >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > >> > >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > >> > >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c > >> Modified: > >> lldb/trunk/source/Target/StackFrame.cpp > >> > >> Added: > >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > >> URL: > >> > http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile?rev=267478&view=auto > >> > >> > == > >> --- > >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > >> (added) > >> +++ > >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > >> Mon Apr 25 16:54:10 2016 > >> @@ -0,0 +1,5 @@ > >> +LEVEL = ../../../make > >> + > >> +C_SOURCES := main.c > >> + > >> +include $(LEVEL)/Makefile.rules > >> > >> Added: > >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > >> URL: > >> > http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py?rev=267478&view=auto > >> > >> > == > >> --- > >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > >> (added) > >> +++ > >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > >> Mon Apr 25 16:54:10 2016 > >> @@ -0,0 +1,190 @@ > >> +""" > >> +Test that SBFrame::GetVariables() calls work correctly. > >> +""" > >> + > >> +from __future__ import print_function > >> + > >> + > >> + > >> +import os, time > >> +import lldb > >> +from lldbsuite.test.decorators import * > >> +from lldbsuite.test.lldbtest import * > >> +from lldbsuite.test import lldbplatform > >> +from lldbsuite.test import lldbutil > >> + > >> +def get_names_from_value_list(value_list): > >> +names = list() > >> +for value in value_list: > >> +names.append(value.GetName()) > >> +return names > >> + > >> +class TestGetVariables(TestBase): > >> + > >> +mydir = TestBase.compute_mydir(__file__) > >> + > >> +def setUp(self): > >> +# Call super's setUp(). > >> +TestBase.setUp(self) > >> +self.source = 'main.c' > >> + > >> +def verify_variable_names(self, description, value_list, names): > >> +copy_names = list(names) > >> +actual_names = get_names_from_value_list(value_list) > >> +for name in actual_names: > >> +if name in copy_names: > >> +copy_names.remove(name) > >> +else: > >> +self.assertTrue(False, "didn't find '%s' in %s" % > (name, > >> copy_names)) > >> +self.assertEqual(len(copy_names), 0, "%s: we didn't find > >> variables: %s in value list (%s)" % (description, copy_names, > actual_names)) > >> + > >> +def test (self): > >> +self.build () > >> + > >> +# Set debugger into synchronous mode > >> +self.dbg.SetAsync(False) > >> + > >> +# Create a target by the debugger. > >> +exe = os.path.join(os.getcwd(), "a.out") > >> +target = self.dbg.CreateTarget(exe) > >> +self.assertTrue(target, VALID_TARGET) > >> + > >> +line1 = line_number(self.source, '// breakpoint 1') > >> +line2 = line_number(self.source, '// breakpoint 2') > >> +line3 = line_number(self.source, '// breakpoint 3') > >> + > >> +breakpoint1 = target.BreakpointCreateByLocation
[Lldb-commits] [PATCH] D19511: Fix TestGetVariables.py.
chaoren created this revision.
chaoren added reviewers: sivachandra, clayborg.
chaoren added a subscriber: lldb-commits.
http://reviews.llvm.org/D19511
Files:
packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
Index: packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
===
--- packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
+++ packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
@@ -12,8 +12,9 @@
static int g_static_var = 123;
int main (int argc, char const *argv[])
-{
+{
static int static_var = 123;
+g_static_var = 123; // clang bug. Need to touch this variable, otherwise
it disappears.
int i = 0; // breakpoint 1
for (i=0; i<1; ++i)
{
Index:
packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
===
---
packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
+++
packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
@@ -79,7 +79,7 @@
arg_names = ['argc', 'argv']
local_names = ['i', 'j', 'k']
-static_names = ['static_var', 'g_global_var', 'static_var']
+static_names = ['static_var', 'g_global_var', 'g_static_var']
breakpoint1_locals = ['i']
breakpoint1_statics = ['static_var']
num_args = len(arg_names)
Index: packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
===
--- packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
+++ packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
@@ -12,8 +12,9 @@
static int g_static_var = 123;
int main (int argc, char const *argv[])
-{
+{
static int static_var = 123;
+g_static_var = 123; // clang bug. Need to touch this variable, otherwise it disappears.
int i = 0; // breakpoint 1
for (i=0; i<1; ++i)
{
Index: packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
===
--- packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
+++ packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
@@ -79,7 +79,7 @@
arg_names = ['argc', 'argv']
local_names = ['i', 'j', 'k']
-static_names = ['static_var', 'g_global_var', 'static_var']
+static_names = ['static_var', 'g_global_var', 'g_static_var']
breakpoint1_locals = ['i']
breakpoint1_statics = ['static_var']
num_args = len(arg_names)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19511: Fix TestGetVariables.py.
This revision was automatically updated to reflect the committed changes.
Closed by commit rL267492: Fix TestGetVariables.py. (authored by chaoren).
Changed prior to commit:
http://reviews.llvm.org/D19511?vs=54940&id=54944#toc
Repository:
rL LLVM
http://reviews.llvm.org/D19511
Files:
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
Index:
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
===
---
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
+++
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
@@ -12,8 +12,9 @@
static int g_static_var = 123;
int main (int argc, char const *argv[])
-{
+{
static int static_var = 123;
+g_static_var = 123; // clang bug. Need to touch this variable, otherwise
it disappears.
int i = 0; // breakpoint 1
for (i=0; i<1; ++i)
{
Index:
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
===
---
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
+++
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
@@ -79,7 +79,7 @@
arg_names = ['argc', 'argv']
local_names = ['i', 'j', 'k']
-static_names = ['static_var', 'g_global_var', 'static_var']
+static_names = ['static_var', 'g_global_var', 'g_static_var']
breakpoint1_locals = ['i']
breakpoint1_statics = ['static_var']
num_args = len(arg_names)
Index: lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
===
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
@@ -12,8 +12,9 @@
static int g_static_var = 123;
int main (int argc, char const *argv[])
-{
+{
static int static_var = 123;
+g_static_var = 123; // clang bug. Need to touch this variable, otherwise it disappears.
int i = 0; // breakpoint 1
for (i=0; i<1; ++i)
{
Index: lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
@@ -79,7 +79,7 @@
arg_names = ['argc', 'argv']
local_names = ['i', 'j', 'k']
-static_names = ['static_var', 'g_global_var', 'static_var']
+static_names = ['static_var', 'g_global_var', 'g_static_var']
breakpoint1_locals = ['i']
breakpoint1_statics = ['static_var']
num_args = len(arg_names)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r267492 - Fix TestGetVariables.py.
Author: chaoren
Date: Mon Apr 25 18:29:53 2016
New Revision: 267492
URL: http://llvm.org/viewvc/llvm-project?rev=267492&view=rev
Log:
Fix TestGetVariables.py.
Reviewers: sivachandra, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19511
Modified:
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
Modified:
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py?rev=267492&r1=267491&r2=267492&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py
Mon Apr 25 18:29:53 2016
@@ -79,7 +79,7 @@ class TestGetVariables(TestBase):
arg_names = ['argc', 'argv']
local_names = ['i', 'j', 'k']
-static_names = ['static_var', 'g_global_var', 'static_var']
+static_names = ['static_var', 'g_global_var', 'g_static_var']
breakpoint1_locals = ['i']
breakpoint1_statics = ['static_var']
num_args = len(arg_names)
Modified:
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c?rev=267492&r1=267491&r2=267492&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c
Mon Apr 25 18:29:53 2016
@@ -12,8 +12,9 @@ int g_global_var = 123;
static int g_static_var = 123;
int main (int argc, char const *argv[])
-{
+{
static int static_var = 123;
+g_static_var = 123; // clang bug. Need to touch this variable, otherwise
it disappears.
int i = 0; // breakpoint 1
for (i=0; i<1; ++i)
{
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r267478 - Fix StackFrame::GetVariables(...) function that was broken by 261858 when lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables
Clang is probably right. Why bother to emit an unused file static scalar? On Mon, Apr 25, 2016 at 4:21 PM, Chaoren Lin wrote: > Ah, I see. Is that a known clang bug? > > On Mon, Apr 25, 2016 at 4:07 PM, Siva Chandra > wrote: >> >> AFAICT, happens only with Clang; Using g_static_var, say as "return >> g_static_var - 123;", fixes for me. >> >> On Mon, Apr 25, 2016 at 3:50 PM, Chaoren Lin via lldb-commits >> wrote: >> > Is g_global_var necessarily static? >> > >> > On Linux, we're only seeing 2 static variables when your test expects 3. >> > >> >> static_names = ['static_var', 'g_global_var', 'static_var'] >> > >> > I'm guessing g_global_var isn't treated as static. >> > >> > On Mon, Apr 25, 2016 at 2:54 PM, Greg Clayton via lldb-commits >> > wrote: >> >> >> >> Author: gclayton >> >> Date: Mon Apr 25 16:54:10 2016 >> >> New Revision: 267478 >> >> >> >> URL: http://llvm.org/viewvc/llvm-project?rev=267478&view=rev >> >> Log: >> >> Fix StackFrame::GetVariables(...) function that was broken by 261858 >> >> when >> >> lambda functions were added to Block::AppendBlockVariables(). The >> >> Stackframe::GetVariables(...) function should get all variables >> >> regardless >> >> if they are in scope. >> >> >> >> This wasn't caught by the test suite so I added a test for it. >> >> >> >> >> >> Added: >> >> >> >> >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/ >> >> >> >> >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile >> >> >> >> >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py >> >> >> >> >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c >> >> Modified: >> >> lldb/trunk/source/Target/StackFrame.cpp >> >> >> >> Added: >> >> >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile >> >> URL: >> >> >> >> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile?rev=267478&view=auto >> >> >> >> >> >> == >> >> --- >> >> >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile >> >> (added) >> >> +++ >> >> >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile >> >> Mon Apr 25 16:54:10 2016 >> >> @@ -0,0 +1,5 @@ >> >> +LEVEL = ../../../make >> >> + >> >> +C_SOURCES := main.c >> >> + >> >> +include $(LEVEL)/Makefile.rules >> >> >> >> Added: >> >> >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py >> >> URL: >> >> >> >> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py?rev=267478&view=auto >> >> >> >> >> >> == >> >> --- >> >> >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py >> >> (added) >> >> +++ >> >> >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py >> >> Mon Apr 25 16:54:10 2016 >> >> @@ -0,0 +1,190 @@ >> >> +""" >> >> +Test that SBFrame::GetVariables() calls work correctly. >> >> +""" >> >> + >> >> +from __future__ import print_function >> >> + >> >> + >> >> + >> >> +import os, time >> >> +import lldb >> >> +from lldbsuite.test.decorators import * >> >> +from lldbsuite.test.lldbtest import * >> >> +from lldbsuite.test import lldbplatform >> >> +from lldbsuite.test import lldbutil >> >> + >> >> +def get_names_from_value_list(value_list): >> >> +names = list() >> >> +for value in value_list: >> >> +names.append(value.GetName()) >> >> +return names >> >> + >> >> +class TestGetVariables(TestBase): >> >> + >> >> +mydir = TestBase.compute_mydir(__file__) >> >> + >> >> +def setUp(self): >> >> +# Call super's setUp(). >> >> +TestBase.setUp(self) >> >> +self.source = 'main.c' >> >> + >> >> +def verify_variable_names(self, description, value_list, names): >> >> +copy_names = list(names) >> >> +actual_names = get_names_from_value_list(value_list) >> >> +for name in actual_names: >> >> +if name in copy_names: >> >> +copy_names.remove(name) >> >> +else: >> >> +self.assertTrue(False, "didn't find '%s' in %s" % >> >> (name, >> >> copy_names)) >> >> +self.assertEqual(len(copy_names), 0, "%s: we didn't find >> >> variables: %s in value list (%s)" % (description, copy_names, >> >> actual_names)) >> >> + >> >> +def test (self): >> >> +self.build () >> >> + >> >> +# Set debugger into synchronous mode >> >> +self.dbg.SetAsync(False) >> >> + >> >> +# Create a target by the debugger. >> >> +exe = os.path.join(os.getcwd(), "a.out") >> >> +target = self.dbg.CreateTarg
[Lldb-commits] [lldb] r267494 - Make sure that the following SymbolFileDWARF functions can handle getting a lldb::user_id_t for another SymbolFileDWARF:
Author: gclayton
Date: Mon Apr 25 18:39:19 2016
New Revision: 267494
URL: http://llvm.org/viewvc/llvm-project?rev=267494&view=rev
Log:
Make sure that the following SymbolFileDWARF functions can handle getting a
lldb::user_id_t for another SymbolFileDWARF:
CompilerDecl
SymbolFileDWARF::GetDeclForUID (lldb::user_id_t type_uid);
CompilerDeclContext
SymbolFileDWARF::GetDeclContextForUID (lldb::user_id_t type_uid)
CompilerDeclContext
SymbolFileDWARF::GetDeclContextContainingUID (lldb::user_id_t type_uid)
Type*
SymbolFileDWARF::ResolveTypeUID (lldb::user_id_t type_uid)
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp?rev=267494&r1=267493&r2=267494&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp Mon Apr 25
18:39:19 2016
@@ -1459,10 +1459,45 @@ SymbolFileDWARF::ParseDeclsForContext (C
ast_parser->GetDeclForUIDFromDWARF(decl);
}
+SymbolFileDWARF *
+SymbolFileDWARF::GetDWARFForUID (lldb::user_id_t uid)
+{
+// Anytime we get a "lldb::user_id_t" from an lldb_private::SymbolFile API
+// we must make sure we use the correct DWARF file when resolving things.
+// On MacOSX, when using SymbolFileDWARFDebugMap, we will use multiple
+// SymbolFileDWARF classes, one for each .o file. We can often end up
+// with references to other DWARF objects and we must be ready to receive
+// a "lldb::user_id_t" that specifies a DIE from another SymbolFileDWARF
+// instance.
+SymbolFileDWARFDebugMap *debug_map = GetDebugMapSymfile();
+if (debug_map)
+return
debug_map->GetSymbolFileByOSOIndex(debug_map->GetOSOIndexFromUserID(uid));
+return this;
+}
+
+DWARFDIE
+SymbolFileDWARF::GetDIEFromUID (lldb::user_id_t uid)
+{
+// Anytime we get a "lldb::user_id_t" from an lldb_private::SymbolFile API
+// we must make sure we use the correct DWARF file when resolving things.
+// On MacOSX, when using SymbolFileDWARFDebugMap, we will use multiple
+// SymbolFileDWARF classes, one for each .o file. We can often end up
+// with references to other DWARF objects and we must be ready to receive
+// a "lldb::user_id_t" that specifies a DIE from another SymbolFileDWARF
+// instance.
+SymbolFileDWARF *dwarf = GetDWARFForUID(uid);
+if (dwarf)
+return dwarf->GetDIE(DIERef(uid, dwarf));
+return DWARFDIE();
+}
+
CompilerDecl
SymbolFileDWARF::GetDeclForUID (lldb::user_id_t type_uid)
{
-DWARFDIE die = GetDIE(DIERef(type_uid, this));
+// Anytime we have a lldb::user_id_t, we must get the DIE by
+// calling SymbolFileDWARF::GetDIEFromUID(). See comments inside
+// the SymbolFileDWARF::GetDIEFromUID() for details.
+DWARFDIE die = GetDIEFromUID(type_uid);
if (die)
return die.GetDecl();
return CompilerDecl();
@@ -1471,7 +1506,10 @@ SymbolFileDWARF::GetDeclForUID (lldb::us
CompilerDeclContext
SymbolFileDWARF::GetDeclContextForUID (lldb::user_id_t type_uid)
{
-DWARFDIE die = GetDIE(DIERef(type_uid, this));
+// Anytime we have a lldb::user_id_t, we must get the DIE by
+// calling SymbolFileDWARF::GetDIEFromUID(). See comments inside
+// the SymbolFileDWARF::GetDIEFromUID() for details.
+DWARFDIE die = GetDIEFromUID(type_uid);
if (die)
return die.GetDeclContext();
return CompilerDeclContext();
@@ -1480,7 +1518,10 @@ SymbolFileDWARF::GetDeclContextForUID (l
CompilerDeclContext
SymbolFileDWARF::GetDeclContextContainingUID (lldb::user_id_t type_uid)
{
-DWARFDIE die = GetDIE (DIERef(type_uid, this));
+// Anytime we have a lldb::user_id_t, we must get the DIE by
+// calling SymbolFileDWARF::GetDIEFromUID(). See comments inside
+// the SymbolFileDWARF::GetDIEFromUID() for details.
+DWARFDIE die = GetDIEFromUID(type_uid);
if (die)
return die.GetContainingDeclContext();
return CompilerDeclContext();
@@ -1490,13 +1531,14 @@ SymbolFileDWARF::GetDeclContextContainin
Type*
SymbolFileDWARF::ResolveTypeUID (lldb::user_id_t type_uid)
{
-DWARFDIE type_die = GetDIE (DIERef(type_uid, this));
+// Anytime we have a lldb::user_id_t, we must get the DIE by
+// calling SymbolFileDWARF::GetDIEFromUID(). See comments inside
+// the SymbolFileDWARF::GetDIEFromUID() for details.
+DWARFDIE type_die = GetDIEFromUID(type_uid);
if (type_die)
-{
-const bool assert_not_being_parsed = true;
-return ResolveTypeUID (type_die, assert_not_being_parsed);
-}
-return NULL;
+return type_die.ResolveType();
+else
+return nullptr;
}
Type*
Modi
Re: [Lldb-commits] [PATCH] D19511: Fix TestGetVariables.py.
clayborg added a comment. Looks good. We will need to remove the darwin only decorator as well to enable this for other platforms. Repository: rL LLVM http://reviews.llvm.org/D19511 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r267500 - When building the list of variables we're going to write "using $_lldb_local_vars"
Author: jingham
Date: Mon Apr 25 19:29:59 2016
New Revision: 267500
URL: http://llvm.org/viewvc/llvm-project?rev=267500&view=rev
Log:
When building the list of variables we're going to write "using
$_lldb_local_vars"
statements for, be sure not to include variables that have no locations. We
wouldn't
be able to realize them, and that will cause all expressions to fail.
Modified:
lldb/trunk/include/lldb/Target/StackFrame.h
lldb/trunk/source/Expression/ExpressionSourceCode.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=267500&r1=267499&r2=267500&view=diff
==
--- lldb/trunk/include/lldb/Target/StackFrame.h (original)
+++ lldb/trunk/include/lldb/Target/StackFrame.h Mon Apr 25 19:29:59 2016
@@ -289,7 +289,7 @@ public:
/// A pointer to a list of variables.
//--
lldb::VariableListSP
-GetInScopeVariableList (bool get_file_globals);
+GetInScopeVariableList (bool get_file_globals, bool
must_have_valid_location = false);
//--
/// Create a ValueObject for a variable name / pathname, possibly
Modified: lldb/trunk/source/Expression/ExpressionSourceCode.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/ExpressionSourceCode.cpp?rev=267500&r1=267499&r2=267500&view=diff
==
--- lldb/trunk/source/Expression/ExpressionSourceCode.cpp (original)
+++ lldb/trunk/source/Expression/ExpressionSourceCode.cpp Mon Apr 25 19:29:59
2016
@@ -278,7 +278,7 @@ bool ExpressionSourceCode::GetText (std:
ConstString object_name;
if (Language::LanguageIsCPlusPlus(frame->GetLanguage()))
{
-lldb::VariableListSP var_list_sp =
frame->GetInScopeVariableList(false);
+lldb::VariableListSP var_list_sp =
frame->GetInScopeVariableList(false, true);
AddLocalVariableDecls(var_list_sp, lldb_local_var_decls);
}
}
Modified: lldb/trunk/source/Target/StackFrame.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/StackFrame.cpp?rev=267500&r1=267499&r2=267500&view=diff
==
--- lldb/trunk/source/Target/StackFrame.cpp (original)
+++ lldb/trunk/source/Target/StackFrame.cpp Mon Apr 25 19:29:59 2016
@@ -571,7 +571,7 @@ StackFrame::GetVariableList (bool get_fi
}
VariableListSP
-StackFrame::GetInScopeVariableList (bool get_file_globals)
+StackFrame::GetInScopeVariableList (bool get_file_globals, bool
must_have_valid_location)
{
Mutex::Locker locker(m_mutex);
// We can't fetch variable information for a history stack frame.
@@ -589,7 +589,10 @@ StackFrame::GetInScopeVariableList (bool
m_sc.block->AppendVariables (can_create,
get_parent_variables,
stop_if_block_is_inlined_function,
- [this](Variable* v) { return
v->IsInScope(this); },
+ [this,
must_have_valid_location](Variable* v)
+ {
+ return v->IsInScope(this) &&
(!must_have_valid_location || v->LocationIsValidForFrame(this));
+ },
var_list_sp.get());
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r267478 - Fix StackFrame::GetVariables(...) function that was broken by 261858 when lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables
Because it's compiled in debug mode? I wouldn't expect *any* optimization to be done in that case. On Mon, Apr 25, 2016 at 4:35 PM, Siva Chandra wrote: > Clang is probably right. Why bother to emit an unused file static scalar? > > On Mon, Apr 25, 2016 at 4:21 PM, Chaoren Lin wrote: > > Ah, I see. Is that a known clang bug? > > > > On Mon, Apr 25, 2016 at 4:07 PM, Siva Chandra > > wrote: > >> > >> AFAICT, happens only with Clang; Using g_static_var, say as "return > >> g_static_var - 123;", fixes for me. > >> > >> On Mon, Apr 25, 2016 at 3:50 PM, Chaoren Lin via lldb-commits > >> wrote: > >> > Is g_global_var necessarily static? > >> > > >> > On Linux, we're only seeing 2 static variables when your test expects > 3. > >> > > >> >> static_names = ['static_var', 'g_global_var', 'static_var'] > >> > > >> > I'm guessing g_global_var isn't treated as static. > >> > > >> > On Mon, Apr 25, 2016 at 2:54 PM, Greg Clayton via lldb-commits > >> > wrote: > >> >> > >> >> Author: gclayton > >> >> Date: Mon Apr 25 16:54:10 2016 > >> >> New Revision: 267478 > >> >> > >> >> URL: http://llvm.org/viewvc/llvm-project?rev=267478&view=rev > >> >> Log: > >> >> Fix StackFrame::GetVariables(...) function that was broken by 261858 > >> >> when > >> >> lambda functions were added to Block::AppendBlockVariables(). The > >> >> Stackframe::GetVariables(...) function should get all variables > >> >> regardless > >> >> if they are in scope. > >> >> > >> >> This wasn't caught by the test suite so I added a test for it. > >> >> > >> >> > >> >> Added: > >> >> > >> >> > >> >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/ > >> >> > >> >> > >> >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > >> >> > >> >> > >> >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > >> >> > >> >> > >> >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c > >> >> Modified: > >> >> lldb/trunk/source/Target/StackFrame.cpp > >> >> > >> >> Added: > >> >> > >> >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > >> >> URL: > >> >> > >> >> > http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile?rev=267478&view=auto > >> >> > >> >> > >> >> > == > >> >> --- > >> >> > >> >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > >> >> (added) > >> >> +++ > >> >> > >> >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > >> >> Mon Apr 25 16:54:10 2016 > >> >> @@ -0,0 +1,5 @@ > >> >> +LEVEL = ../../../make > >> >> + > >> >> +C_SOURCES := main.c > >> >> + > >> >> +include $(LEVEL)/Makefile.rules > >> >> > >> >> Added: > >> >> > >> >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > >> >> URL: > >> >> > >> >> > http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py?rev=267478&view=auto > >> >> > >> >> > >> >> > == > >> >> --- > >> >> > >> >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > >> >> (added) > >> >> +++ > >> >> > >> >> > lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > >> >> Mon Apr 25 16:54:10 2016 > >> >> @@ -0,0 +1,190 @@ > >> >> +""" > >> >> +Test that SBFrame::GetVariables() calls work correctly. > >> >> +""" > >> >> + > >> >> +from __future__ import print_function > >> >> + > >> >> + > >> >> + > >> >> +import os, time > >> >> +import lldb > >> >> +from lldbsuite.test.decorators import * > >> >> +from lldbsuite.test.lldbtest import * > >> >> +from lldbsuite.test import lldbplatform > >> >> +from lldbsuite.test import lldbutil > >> >> + > >> >> +def get_names_from_value_list(value_list): > >> >> +names = list() > >> >> +for value in value_list: > >> >> +names.append(value.GetName()) > >> >> +return names > >> >> + > >> >> +class TestGetVariables(TestBase): > >> >> + > >> >> +mydir = TestBase.compute_mydir(__file__) > >> >> + > >> >> +def setUp(self): > >> >> +# Call super's setUp(). > >> >> +TestBase.setUp(self) > >> >> +self.source = 'main.c' > >> >> + > >> >> +def verify_variable_names(self, description, value_list, names): > >> >> +copy_names = list(names) > >> >> +actual_names = get_names_from_value_list(value_list) > >> >> +for name in actual_names: > >> >> +if name in copy_names: > >> >> +copy_names.remove(name) > >> >> +else: > >> >> +self.assertTrue(False, "didn't find '%s' in %s" % > >> >> (name, > >> >> copy_names)) > >> >> +self.a
Re: [Lldb-commits] [lldb] r267478 - Fix StackFrame::GetVariables(...) function that was broken by 261858 when lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables
Debug mode doesn't mean no optimization, but -O0 SHOULD... OTOH, long experience has shown that it is very hard to convince compilers to be as dumb at -O0 as you would like them to be. That's why in all our test cases, we initialize variables, and generally do something dumb like printf the variable so the compiler thinks it is actually being used. Jim > On Apr 25, 2016, at 5:37 PM, Chaoren Lin via lldb-commits > wrote: > > Because it's compiled in debug mode? I wouldn't expect *any* optimization to > be done in that case. > > On Mon, Apr 25, 2016 at 4:35 PM, Siva Chandra wrote: > Clang is probably right. Why bother to emit an unused file static scalar? > > On Mon, Apr 25, 2016 at 4:21 PM, Chaoren Lin wrote: > > Ah, I see. Is that a known clang bug? > > > > On Mon, Apr 25, 2016 at 4:07 PM, Siva Chandra > > wrote: > >> > >> AFAICT, happens only with Clang; Using g_static_var, say as "return > >> g_static_var - 123;", fixes for me. > >> > >> On Mon, Apr 25, 2016 at 3:50 PM, Chaoren Lin via lldb-commits > >> wrote: > >> > Is g_global_var necessarily static? > >> > > >> > On Linux, we're only seeing 2 static variables when your test expects 3. > >> > > >> >> static_names = ['static_var', 'g_global_var', 'static_var'] > >> > > >> > I'm guessing g_global_var isn't treated as static. > >> > > >> > On Mon, Apr 25, 2016 at 2:54 PM, Greg Clayton via lldb-commits > >> > wrote: > >> >> > >> >> Author: gclayton > >> >> Date: Mon Apr 25 16:54:10 2016 > >> >> New Revision: 267478 > >> >> > >> >> URL: http://llvm.org/viewvc/llvm-project?rev=267478&view=rev > >> >> Log: > >> >> Fix StackFrame::GetVariables(...) function that was broken by 261858 > >> >> when > >> >> lambda functions were added to Block::AppendBlockVariables(). The > >> >> Stackframe::GetVariables(...) function should get all variables > >> >> regardless > >> >> if they are in scope. > >> >> > >> >> This wasn't caught by the test suite so I added a test for it. > >> >> > >> >> > >> >> Added: > >> >> > >> >> > >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/ > >> >> > >> >> > >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > >> >> > >> >> > >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > >> >> > >> >> > >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/main.c > >> >> Modified: > >> >> lldb/trunk/source/Target/StackFrame.cpp > >> >> > >> >> Added: > >> >> > >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > >> >> URL: > >> >> > >> >> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile?rev=267478&view=auto > >> >> > >> >> > >> >> == > >> >> --- > >> >> > >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > >> >> (added) > >> >> +++ > >> >> > >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/Makefile > >> >> Mon Apr 25 16:54:10 2016 > >> >> @@ -0,0 +1,5 @@ > >> >> +LEVEL = ../../../make > >> >> + > >> >> +C_SOURCES := main.c > >> >> + > >> >> +include $(LEVEL)/Makefile.rules > >> >> > >> >> Added: > >> >> > >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > >> >> URL: > >> >> > >> >> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py?rev=267478&view=auto > >> >> > >> >> > >> >> == > >> >> --- > >> >> > >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > >> >> (added) > >> >> +++ > >> >> > >> >> lldb/trunk/packages/Python/lldbsuite/test/python_api/frame/get-variables/TestGetVariables.py > >> >> Mon Apr 25 16:54:10 2016 > >> >> @@ -0,0 +1,190 @@ > >> >> +""" > >> >> +Test that SBFrame::GetVariables() calls work correctly. > >> >> +""" > >> >> + > >> >> +from __future__ import print_function > >> >> + > >> >> + > >> >> + > >> >> +import os, time > >> >> +import lldb > >> >> +from lldbsuite.test.decorators import * > >> >> +from lldbsuite.test.lldbtest import * > >> >> +from lldbsuite.test import lldbplatform > >> >> +from lldbsuite.test import lldbutil > >> >> + > >> >> +def get_names_from_value_list(value_list): > >> >> +names = list() > >> >> +for value in value_list: > >> >> +names.append(value.GetName()) > >> >> +return names > >> >> + > >> >> +class TestGetVariables(TestBase): > >> >> + > >> >> +mydir = TestBase.compute_mydir(__file__) > >> >> + > >> >> +def setUp(self): > >> >> +# Call super's setUp(). > >> >> +TestBase.setUp(self) > >> >> +self.source = 'main.c' > >> >> + > >> >> +def verify_variable_names(self, description, value_list,
[Lldb-commits] [lldb] r267508 - Fix arm-linux-gnueabi regression due to rL267291
Author: omjavaid Date: Mon Apr 25 20:08:59 2016 New Revision: 267508 URL: http://llvm.org/viewvc/llvm-project?rev=267508&view=rev Log: Fix arm-linux-gnueabi regression due to rL267291 rL267291 introduces a lot regression on arm-linux LLDB testsuite. This patch fixes half of them. I am merging it under already revied android counterpart. Another patch fixing rest of the issue will follow this commit. Differential revision: http://reviews.llvm.org/D19480 Modified: lldb/trunk/source/Core/ArchSpec.cpp Modified: lldb/trunk/source/Core/ArchSpec.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ArchSpec.cpp?rev=267508&r1=267507&r2=267508&view=diff == --- lldb/trunk/source/Core/ArchSpec.cpp (original) +++ lldb/trunk/source/Core/ArchSpec.cpp Mon Apr 25 20:08:59 2016 @@ -1016,7 +1016,11 @@ isCompatibleEnvironment(llvm::Triple::En // be compatible. This is required as a workaround for shared libraries compiled for Android // without the NOTE section indicating that they are using the Android ABI. if ((lhs == llvm::Triple::Android && rhs == llvm::Triple::EABI) || -(rhs == llvm::Triple::Android && lhs == llvm::Triple::EABI)) +(rhs == llvm::Triple::Android && lhs == llvm::Triple::EABI) || +(lhs == llvm::Triple::GNUEABI && rhs == llvm::Triple::EABI) || +(rhs == llvm::Triple::GNUEABI && lhs == llvm::Triple::EABI) || +(lhs == llvm::Triple::GNUEABIHF && rhs == llvm::Triple::EABIHF) || +(rhs == llvm::Triple::GNUEABIHF && lhs == llvm::Triple::EABIHF)) return true; return false; ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D19520: rL267291: Architecture change to thumb on parsing arm.attributes causes regression.
omjavaid created this revision.
omjavaid added reviewers: tberghammer, labath.
omjavaid added a subscriber: lldb-commits.
Herald added subscribers: rengolin, aemerson.
rL267291 introduces a lot of regression on arm-linux by fixing module
architecture to thumb if it finds thumb32 tag set.
Tag_THUMB_ISA_use, (=9), uleb128
2 32-bit Thumb instructions were permitted (implies 16-bit instructions
permitted)
Does not mean that there wont be any arm instruction in current module.
Therefore we can not set the architecture to thumb without knowing the value of
Tag_ARM_ISA_use, (=8), uleb128
0 The user did not permit this entity to use ARM instructions
1 The user intended that this entity could use ARM instructions
For most cases Tag_ARM_ISA_use, (=8), uleb128 will be set to 1 that will force
us to use arm as our architecture instead of thumb.
I am removing this code for now may be we can come up with a better solution to
get it over with.
http://reviews.llvm.org/D19520
Files:
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1564,19 +1564,6 @@
break;
-case llvm::ARMBuildAttrs::THUMB_ISA_use:
-{
-uint64_t ThumbISA = data.GetULEB128(&Offset);
-
-// NOTE: ignore ThumbISA ==
llvm::ARMBuildAttrs::AllowThumbDerived
-// since that derives it based on the architecutre/profile
-if (ThumbISA == llvm::ARMBuildAttrs::AllowThumb32)
-if (arch_spec.GetTriple().getArch() ==
llvm::Triple::UnknownArch ||
-arch_spec.GetTriple().getArch() ==
llvm::Triple::arm)
-arch_spec.GetTriple().setArch(llvm::Triple::thumb);
-
-break;
-}
case llvm::ARMBuildAttrs::ABI_VFP_args:
{
uint64_t VFPArgs = data.GetULEB128(&Offset);
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1564,19 +1564,6 @@
break;
-case llvm::ARMBuildAttrs::THUMB_ISA_use:
-{
-uint64_t ThumbISA = data.GetULEB128(&Offset);
-
-// NOTE: ignore ThumbISA == llvm::ARMBuildAttrs::AllowThumbDerived
-// since that derives it based on the architecutre/profile
-if (ThumbISA == llvm::ARMBuildAttrs::AllowThumb32)
-if (arch_spec.GetTriple().getArch() == llvm::Triple::UnknownArch ||
-arch_spec.GetTriple().getArch() == llvm::Triple::arm)
-arch_spec.GetTriple().setArch(llvm::Triple::thumb);
-
-break;
-}
case llvm::ARMBuildAttrs::ABI_VFP_args:
{
uint64_t VFPArgs = data.GetULEB128(&Offset);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19214: fix a race is the LLDB test suite results collection
Awesome! Good catch, Adrian! (And my pleasure!) -Todd > On Apr 25, 2016, at 4:13 PM, Adrian McCarthy wrote: > > amccarth added a comment. > > I got it. There was an exception being thrown from asyncore so early that it > didn't give a proper stack trace. The problem boils down to Python 3 drawing > a distinction between strings and bytearrays. Patch to come momentarily. > > Thanks for your help. > > > http://reviews.llvm.org/D19214 > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19214: fix a race is the LLDB test suite results collection
tfiala added a subscriber: tfiala. tfiala added a comment. Awesome! Good catch, Adrian! (And my pleasure!) -Todd http://reviews.llvm.org/D19214 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
