[Lldb-commits] [lldb] r321255 - Make sure DataBufferLLVM contents are writable
Author: labath
Date: Thu Dec 21 02:54:30 2017
New Revision: 321255
URL: http://llvm.org/viewvc/llvm-project?rev=321255&view=rev
Log:
Make sure DataBufferLLVM contents are writable
Summary:
We sometimes need to write to the object file we've mapped into memory,
generally to apply relocations to debug info sections. We've had that
ability before, but with the introduction of DataBufferLLVM, we have
lost it, as the underlying llvm class (MemoryBuffer) only supports
read-only mappings.
This switches DataBufferLLVM to use the new llvm::WritableMemoryBuffer
class as a back-end, as this one guarantees to return a writable buffer.
This removes the need for the "Private" flag to the DataBufferLLVM
creation functions, as it was really used to mean "writable". The LLVM
function also does not have the NullTerminate flag, so I've modified our
clients to not require this feature and removed that flag as well.
Reviewers: zturner, clayborg, jingham
Subscribers: emaste, aprantl, arichardson, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D40079
Modified:
lldb/trunk/include/lldb/Interpreter/OptionValueFileSpec.h
lldb/trunk/include/lldb/Symbol/ObjectFile.h
lldb/trunk/include/lldb/Target/Target.h
lldb/trunk/include/lldb/Utility/DataBufferLLVM.h
lldb/trunk/source/Interpreter/OptionValueFileSpec.cpp
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
lldb/trunk/source/Symbol/ObjectFile.cpp
lldb/trunk/source/Target/Target.cpp
lldb/trunk/source/Utility/DataBufferLLVM.cpp
Modified: lldb/trunk/include/lldb/Interpreter/OptionValueFileSpec.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Interpreter/OptionValueFileSpec.h?rev=321255&r1=321254&r2=321255&view=diff
==
--- lldb/trunk/include/lldb/Interpreter/OptionValueFileSpec.h (original)
+++ lldb/trunk/include/lldb/Interpreter/OptionValueFileSpec.h Thu Dec 21
02:54:30 2017
@@ -77,7 +77,7 @@ public:
void SetDefaultValue(const FileSpec &value) { m_default_value = value; }
- const lldb::DataBufferSP &GetFileContents(bool null_terminate);
+ const lldb::DataBufferSP &GetFileContents();
void SetCompletionMask(uint32_t mask) { m_completion_mask = mask; }
Modified: lldb/trunk/include/lldb/Symbol/ObjectFile.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/ObjectFile.h?rev=321255&r1=321254&r2=321255&view=diff
==
--- lldb/trunk/include/lldb/Symbol/ObjectFile.h (original)
+++ lldb/trunk/include/lldb/Symbol/ObjectFile.h Thu Dec 21 02:54:30 2017
@@ -879,6 +879,9 @@ protected:
ConstString GetNextSyntheticSymbolName();
+ static lldb::DataBufferSP MapFileData(const FileSpec &file, uint64_t Size,
+uint64_t Offset);
+
private:
DISALLOW_COPY_AND_ASSIGN(ObjectFile);
};
Modified: lldb/trunk/include/lldb/Target/Target.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Target.h?rev=321255&r1=321254&r2=321255&view=diff
==
--- lldb/trunk/include/lldb/Target/Target.h (original)
+++ lldb/trunk/include/lldb/Target/Target.h Thu Dec 21 02:54:30 2017
@@ -161,7 +161,7 @@ public:
lldb::LanguageType GetLanguage() const;
- const char *GetExpressionPrefixContentsAsCString();
+ llvm::StringRef GetExpressionPrefixContents();
bool GetUseHexImmediates() const;
Modified: lldb/trunk/include/lldb/Utility/DataBufferLLVM.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/DataBufferLLVM.h?rev=321255&r1=321254&r2=321255&view=diff
==
--- lldb/trunk/include/lldb/Utility/DataBufferLLVM.h (original)
+++ lldb/trunk/include/lldb/Utility/DataBufferLLVM.h Thu Dec 21 02:54:30 2017
@@ -17,7 +17,7 @@
#include // for uint8_t, uint64_t
namespace llvm {
-class MemoryBuffer;
+class WritableMemoryBuffer;
class Twine;
}
@@ -28,10 +28,10 @@ public:
~DataBufferLLVM();
static std::shared_ptr
- CreateSliceFromPath(const llvm::Twine &Path, uint64_t Size, uint64_t Offset,
bool Private = false);
+ CreateSliceFromPath(const llvm::Twine &Path, uint64_t Size, uint64_t Offset);
static std::shared_ptr
- CreateFromPath(const llvm::Twine &Path, bool NullTerminate = false, bool
Private = false);
+ CreateFromPath(const llvm::Twine &Path);
uint8_t *GetBytes() override;
const uint8_t *GetBytes() const override;
@@ -42,10 +42,9 @@ public:
private:
/// \brief Construct a DataBufferLLVM from \p Buffer. \p Buffer must be a
/// valid pointer.
- explicit DataBufferLLVM(std::u
[Lldb-commits] [PATCH] D40079: Make sure DataBufferLLVM contents are writable
This revision was automatically updated to reflect the committed changes.
Closed by commit rL321255: Make sure DataBufferLLVM contents are writable
(authored by labath, committed by ).
Repository:
rL LLVM
https://reviews.llvm.org/D40079
Files:
lldb/trunk/include/lldb/Interpreter/OptionValueFileSpec.h
lldb/trunk/include/lldb/Symbol/ObjectFile.h
lldb/trunk/include/lldb/Target/Target.h
lldb/trunk/include/lldb/Utility/DataBufferLLVM.h
lldb/trunk/source/Interpreter/OptionValueFileSpec.cpp
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
lldb/trunk/source/Symbol/ObjectFile.cpp
lldb/trunk/source/Target/Target.cpp
lldb/trunk/source/Utility/DataBufferLLVM.cpp
Index: lldb/trunk/include/lldb/Symbol/ObjectFile.h
===
--- lldb/trunk/include/lldb/Symbol/ObjectFile.h
+++ lldb/trunk/include/lldb/Symbol/ObjectFile.h
@@ -879,6 +879,9 @@
ConstString GetNextSyntheticSymbolName();
+ static lldb::DataBufferSP MapFileData(const FileSpec &file, uint64_t Size,
+uint64_t Offset);
+
private:
DISALLOW_COPY_AND_ASSIGN(ObjectFile);
};
Index: lldb/trunk/include/lldb/Utility/DataBufferLLVM.h
===
--- lldb/trunk/include/lldb/Utility/DataBufferLLVM.h
+++ lldb/trunk/include/lldb/Utility/DataBufferLLVM.h
@@ -17,7 +17,7 @@
#include // for uint8_t, uint64_t
namespace llvm {
-class MemoryBuffer;
+class WritableMemoryBuffer;
class Twine;
}
@@ -28,10 +28,10 @@
~DataBufferLLVM();
static std::shared_ptr
- CreateSliceFromPath(const llvm::Twine &Path, uint64_t Size, uint64_t Offset, bool Private = false);
+ CreateSliceFromPath(const llvm::Twine &Path, uint64_t Size, uint64_t Offset);
static std::shared_ptr
- CreateFromPath(const llvm::Twine &Path, bool NullTerminate = false, bool Private = false);
+ CreateFromPath(const llvm::Twine &Path);
uint8_t *GetBytes() override;
const uint8_t *GetBytes() const override;
@@ -42,10 +42,9 @@
private:
/// \brief Construct a DataBufferLLVM from \p Buffer. \p Buffer must be a
/// valid pointer.
- explicit DataBufferLLVM(std::unique_ptr Buffer);
- const uint8_t *GetBuffer() const;
+ explicit DataBufferLLVM(std::unique_ptr Buffer);
- std::unique_ptr Buffer;
+ std::unique_ptr Buffer;
};
}
Index: lldb/trunk/include/lldb/Interpreter/OptionValueFileSpec.h
===
--- lldb/trunk/include/lldb/Interpreter/OptionValueFileSpec.h
+++ lldb/trunk/include/lldb/Interpreter/OptionValueFileSpec.h
@@ -77,7 +77,7 @@
void SetDefaultValue(const FileSpec &value) { m_default_value = value; }
- const lldb::DataBufferSP &GetFileContents(bool null_terminate);
+ const lldb::DataBufferSP &GetFileContents();
void SetCompletionMask(uint32_t mask) { m_completion_mask = mask; }
Index: lldb/trunk/include/lldb/Target/Target.h
===
--- lldb/trunk/include/lldb/Target/Target.h
+++ lldb/trunk/include/lldb/Target/Target.h
@@ -161,7 +161,7 @@
lldb::LanguageType GetLanguage() const;
- const char *GetExpressionPrefixContentsAsCString();
+ llvm::StringRef GetExpressionPrefixContents();
bool GetUseHexImmediates() const;
Index: lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
===
--- lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
+++ lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
@@ -1173,7 +1173,7 @@
xcode_dir_path.append("/usr/share/xcode-select/xcode_dir_path");
temp_file_spec.SetFile(xcode_dir_path, false);
auto dir_buffer =
- DataBufferLLVM::CreateFromPath(temp_file_spec.GetPath(), true);
+ DataBufferLLVM::CreateFromPath(temp_file_spec.GetPath());
if (dir_buffer && dir_buffer->GetByteSize() > 0) {
llvm::StringRef path_ref(dir_buffer->GetChars());
// Trim tailing newlines and make sure there is enough room for a null
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
@@ -24,7 +24,6 @@
#include "lldb/Target/Target.h"
#include "lldb/Utility/ArchSpec.h"
#include "lldb/Utility/DataBufferHeap.h"
-#include "lldb/Utility/DataBufferLLVM.h"
#include "lldb/Utility/Log.h"
#include "lldb/Utility/Status.h"
#include "lldb/Utility/Stream.h"
@@ -406,8 +405,7 @@
lldb::offset_t file_offset,
lldb::offset_t len
[Lldb-commits] [PATCH] D41352: debugserver: Propagate environment in launch-mode (pr35671)
labath added inline comments.
Comment at: tools/debugserver/source/debugserver.cpp:1426
+for (i = 0; (env_entry = host_env[i]) != NULL; ++i)
+ remote->Context().PushEnvironment(env_entry);
+ }
clayborg wrote:
> We need to check if the env var is already in the environment in
> remote->Context() first before pushing the new version. I would assume that
> if you exec a program with an env like:
> ```
> FOO=bar
> USER=me
> FOO=baz
> ```
>
> That FOO=baz will end up being the value that is used. If the user specifies
> things with --env, we will just overwrite it. We might add a
> PushEnvironmentIfNeeded() function to the Context() class that will make sure
> it isn't in the list first and push it only if needed.
That isn't what happens. The execve() will just forward both definitions (you
can see this by exec-ing /usr/bin/env, which will print both), but getenv()
will return the first one. (at least on darwin and linux, but I expect others
to behave the same).
I tried this out as while working on D41359, I got the impression that there is
some confusion about what the code expected to happen when it called
env.AppendArguments() -- e.g. should `SBLaunchInfo::SetEnvironmentEntries(...,
append=true)` overwrite the existing entries or not? Based on these
experiments, I replaced AppendArguments call with `env.insert(...)` (which does
not overwrite), but it's possible some of these should actually by replaced by
`insert_or_assign`..
That said, I agree that relying on this behavior here is dodgy. I'll see if I
can remove it.
Comment at: unittests/tools/lldb-server/tests/LLGSTest.cpp:35
+ // Test that --env takes precedence over inherited environment variables.
+ putenv(const_cast("LLDB_TEST_MAGIC_VARIABLE=foobar"));
+
This test shows that the `--env` below wins over this value from the parent
environment (the test inferior will check it's own environment via getenv and
report the result via exit status)
https://reviews.llvm.org/D41352
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r321271 - Work around test failures on red-hat linux
Author: labath
Date: Thu Dec 21 06:40:03 2017
New Revision: 321271
URL: http://llvm.org/viewvc/llvm-project?rev=321271&view=rev
Log:
Work around test failures on red-hat linux
Two tests were failing because the debugger was picking up multiply
defined internal symbols from the system libraries. This is a bug, as
there should be no ambiguity because the tests are defining variables
with should shadow these symbols, but lldb is not smart enough to figure
that out.
I work around the issue by renaming the variables in these tests, and in
exchange I create a self-contained test which reproduces the issue
without depending on the system libraries.
This increases the predictability of our test suite.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/main.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py?rev=321271&r1=321270&r2=321271&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
Thu Dec 21 06:40:03 2017
@@ -42,7 +42,7 @@ class Radar9673644TestCase(TestBase):
# rdar://problem/9673664 lldb expression evaluation problem
-self.expect('expr char c[] = "foo"; c[0]',
+self.expect('expr char str[] = "foo"; str[0]',
substrs=["'f'"])
# runCmd: expr char c[] = "foo"; c[0]
# output: (char) $0 = 'f'
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py?rev=321271&r1=321270&r2=321271&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
Thu Dec 21 06:40:03 2017
@@ -16,6 +16,13 @@ class TestConflictingSymbols(TestBase):
mydir = TestBase.compute_mydir(__file__)
NO_DEBUG_INFO_TESTCASE = True
+def setUp(self):
+TestBase.setUp(self)
+
+self.One_line = line_number('One/One.c', '// break here')
+self.Two_line = line_number('Two/Two.c', '// break here')
+self.main_line = line_number('main.c', '// break here')
+
def test_conflicting_symbols(self):
self.build()
exe = os.path.join(os.getcwd(), "a.out")
@@ -27,15 +34,12 @@ class TestConflictingSymbols(TestBase):
environment = self.registerSharedLibrariesWithTarget(
target, ['One', 'Two'])
-One_line = line_number('One/One.c', '// break here')
-Two_line = line_number('Two/Two.c', '// break here')
-main_line = line_number('main.c', '// break here')
lldbutil.run_break_set_command(
-self, 'breakpoint set -f One.c -l %s' % (One_line))
+self, 'breakpoint set -f One.c -l %s' % (self.One_line))
lldbutil.run_break_set_command(
-self, 'breakpoint set -f Two.c -l %s' % (Two_line))
+self, 'breakpoint set -f Two.c -l %s' % (self.Two_line))
lldbutil.run_break_set_by_file_and_line(
-self, 'main.c', main_line, num_expected_locations=1,
loc_exact=True)
+self, 'main.c', self.main_line, num_expected_locations=1,
loc_exact=True)
process = target.LaunchSimple(
None, environment, self.get_process_working_directory())
@@ -88,3 +92,32 @@ class TestConflictingSymbols(TestBase):
error=True,
substrs=[
"Multiple internal symbols"])
+
+@expectedFailureAll(bugnumber="llvm.org/pr35043")
+def test_shadowed(self):
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+target = self.dbg.CreateTarget("a.out")
+self.assertTrue(target, VALID_TARGET)
+
+# Register our shared libraries for remote targets so they get
+# automatically uploaded
+environment = self.registerSharedLibrariesWithTarget(
+target, ['One', 'Two'])
+
+lldbutil.run_break_set_by_file_and_line(self, 'main.c', self.main_line)
+
+process = target.LaunchSimple(
+None, environment, self.get_process_working_directory())
+self.assertTrue(process, PROCESS_IS_VALID)
+
+# The stop reason of t
Re: [Lldb-commits] [lldb] r321271 - Work around test failures on red-hat linux
Thank you Pavel.
I was really nervous about making this change but I agree it's for the best.
Thanks,
--
Davide
On Thu, Dec 21, 2017 at 3:40 PM, Pavel Labath via lldb-commits
wrote:
> Author: labath
> Date: Thu Dec 21 06:40:03 2017
> New Revision: 321271
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321271&view=rev
> Log:
> Work around test failures on red-hat linux
>
> Two tests were failing because the debugger was picking up multiply
> defined internal symbols from the system libraries. This is a bug, as
> there should be no ambiguity because the tests are defining variables
> with should shadow these symbols, but lldb is not smart enough to figure
> that out.
>
> I work around the issue by renaming the variables in these tests, and in
> exchange I create a self-contained test which reproduces the issue
> without depending on the system libraries.
>
> This increases the predictability of our test suite.
>
> Modified:
>
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
>
> lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/main.cpp
>
> Modified:
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py?rev=321271&r1=321270&r2=321271&view=diff
> ==
> ---
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
> (original)
> +++
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
> Thu Dec 21 06:40:03 2017
> @@ -42,7 +42,7 @@ class Radar9673644TestCase(TestBase):
>
> # rdar://problem/9673664 lldb expression evaluation problem
>
> -self.expect('expr char c[] = "foo"; c[0]',
> +self.expect('expr char str[] = "foo"; str[0]',
> substrs=["'f'"])
> # runCmd: expr char c[] = "foo"; c[0]
> # output: (char) $0 = 'f'
>
> Modified:
> lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py?rev=321271&r1=321270&r2=321271&view=diff
> ==
> ---
> lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
> (original)
> +++
> lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
> Thu Dec 21 06:40:03 2017
> @@ -16,6 +16,13 @@ class TestConflictingSymbols(TestBase):
> mydir = TestBase.compute_mydir(__file__)
> NO_DEBUG_INFO_TESTCASE = True
>
> +def setUp(self):
> +TestBase.setUp(self)
> +
> +self.One_line = line_number('One/One.c', '// break here')
> +self.Two_line = line_number('Two/Two.c', '// break here')
> +self.main_line = line_number('main.c', '// break here')
> +
> def test_conflicting_symbols(self):
> self.build()
> exe = os.path.join(os.getcwd(), "a.out")
> @@ -27,15 +34,12 @@ class TestConflictingSymbols(TestBase):
> environment = self.registerSharedLibrariesWithTarget(
> target, ['One', 'Two'])
>
> -One_line = line_number('One/One.c', '// break here')
> -Two_line = line_number('Two/Two.c', '// break here')
> -main_line = line_number('main.c', '// break here')
> lldbutil.run_break_set_command(
> -self, 'breakpoint set -f One.c -l %s' % (One_line))
> +self, 'breakpoint set -f One.c -l %s' % (self.One_line))
> lldbutil.run_break_set_command(
> -self, 'breakpoint set -f Two.c -l %s' % (Two_line))
> +self, 'breakpoint set -f Two.c -l %s' % (self.Two_line))
> lldbutil.run_break_set_by_file_and_line(
> -self, 'main.c', main_line, num_expected_locations=1,
> loc_exact=True)
> +self, 'main.c', self.main_line, num_expected_locations=1,
> loc_exact=True)
>
> process = target.LaunchSimple(
> None, environment, self.get_process_working_directory())
> @@ -88,3 +92,32 @@ class TestConflictingSymbols(TestBase):
> error=True,
> substrs=[
> "Multiple internal symbols"])
> +
> +@expectedFailureAll(bugnumber="llvm.org/pr35043")
> +def test_shadowed(self):
> +self.build()
> +exe = os.path.join(os.getcwd(), "a.out")
> +target = self.dbg.CreateTarget("a.out")
> +self.assertTrue(target, VALID_TARGET)
> +
> +# Register our shared libraries for remote targets so they get
> +# automatically uplo
[Lldb-commits] [PATCH] D41427: [lldb] Fix crash when parsing the type of a function without any arguments
davide added a comment. Indeed, this needs to be tested. Repository: rL LLVM https://reviews.llvm.org/D41427 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r319516 - ClangASTContext::ParseClassTemplateDecl doesn't always succeed.
ping? On Mon, Dec 11, 2017 at 12:55 AM, Davide Italiano wrote: > ping. Any luck trying to write a testcase? > This is a great opportunity to discuss whether is feasible and we can > improve the testing strategy here. > > -- > Davide > > On Fri, Dec 1, 2017 at 11:02 AM, Davide Italiano > wrote: >> yes, that should work, and we should give it at least a shot :) >> >> On Fri, Dec 1, 2017 at 11:01 AM, Zachary Turner wrote: >>> As you said a smaller repro is needed, but I'm imagining a case where we can >>> write a file containing some C++ code that uses a template that LLDB doesn't >>> understand, compile it with clang to generate some DWARF, and then run >>> `lldb-test clang-ast a.out`, where the clang-ast subcommand loads the file, >>> builds an AST out of it, and then dumps the contents of the AST into some >>> human readable format to stdout. >>> >>> If clang won't generate this kind of DWARF, we could always use yaml2obj to >>> write the dwarf ourselves. >>> >>> On Fri, Dec 1, 2017 at 10:49 AM Jim Ingham via lldb-commits >>> wrote: The immediate failure - not checking for NULL from an API that can return NULL - is more the sort of thing you should enforce in code not by testing, either by having the API return some kind of empty object that clients can deal with in a regular way, or by using something like llvm's forced check errors. You wouldn't want to use an assert here because it will be a while before lldb can claim to handle every kind of template C++ can produce, so you really just want to fail gracefully. However, this API is used in only one place in lldb, and is really a subroutine for code comprehension and is unlikely to get other uses. So I'm fine with just checking for null at its one usage site. The failure shows that we don't yet support all template kinds in lldb, and that we don't have enough testing for a wide variety of C++ template types. Adrian found one instance of this failure, but it is in the Swift compiler so I need to make a smaller repro case first, then add a test for that type. The longer term plan for this was supposed to be getting lldb & the llvm dwarf parser unified, writing a test harness independent of lldb that you could just cons up and push a wide variety of DWARF at, fuzz test, etc. That effort seems to have stalled, however. For the nonce, when we find failures like this, we add them to the lldb testsuite. But the test that we could ingest this one type - once we fix it so we can - wouldn't tickle this failure anyway, so that effort is really orthogonal to this patch. Jim > On Nov 30, 2017, at 9:45 PM, Davide Italiano > wrote: > > On Thu, Nov 30, 2017 at 7:41 PM, Jim Ingham via lldb-commits > wrote: >> Author: jingham >> Date: Thu Nov 30 19:41:30 2017 >> New Revision: 319516 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=319516&view=rev >> Log: >> ClangASTContext::ParseClassTemplateDecl doesn't always succeed. >> When it does, it returns a NULL ClassTemplateDecl. Don't use >> it if it is NULL... >> >> >> > > Is there a way to test this? There should be one. > Not an expert in the ASTContext, so please feel free to correct me if > I'm wrong. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r320240 - Update PlatformDarwin::GetDeveloperDir to handle the two
Jason, any chance we can write a test case for this?
--
Davide
On Mon, Dec 11, 2017 at 12:52 AM, Davide Italiano wrote:
> Testcase?
>
> On Fri, Dec 8, 2017 at 7:06 PM, Jason Molenda via lldb-commits
> wrote:
>> Author: jmolenda
>> Date: Fri Dec 8 19:06:19 2017
>> New Revision: 320240
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=320240&view=rev
>> Log:
>> Update PlatformDarwin::GetDeveloperDir to handle the two
>> most common cases where the Xcode.app bundle puts lldb -
>> either as a default part of the bundle, or in a toolchain
>> subdirectory, so the platform subclasses can find files
>> relative to this directory.
>>
>> Dropped support for handling the case where the lldb
>> framework was in /Library/PrivateFrameworks. I think
>> this was intended to handle the case where lldb is installed
>> in / (outside the Xcode.app bundle) - but in that case, we
>> can look in the raw directory file paths to find anything.
>>
>>
>>
>> Modified:
>> lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
>>
>> Modified: lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp?rev=320240&r1=320239&r2=320240&view=diff
>> ==
>> --- lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp (original)
>> +++ lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp Fri Dec 8
>> 19:06:19 2017
>> @@ -1132,28 +1132,33 @@ bool PlatformDarwin::ARMGetSupportedArch
>>return false;
>> }
>>
>> +// Return a directory path like /Applications/Xcode.app/Contents/Developer
>> const char *PlatformDarwin::GetDeveloperDirectory() {
>>std::lock_guard guard(m_mutex);
>>if (m_developer_directory.empty()) {
>> bool developer_dir_path_valid = false;
>> char developer_dir_path[PATH_MAX];
>> FileSpec temp_file_spec;
>> +
>> +// Get the lldb framework's file path, and if it exists, truncate some
>> +// components to only the developer directory path.
>> if (HostInfo::GetLLDBPath(ePathTypeLLDBShlibDir, temp_file_spec)) {
>>if (temp_file_spec.GetPath(developer_dir_path,
>> sizeof(developer_dir_path))) {
>> +// e.g.
>> /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework
>> char *shared_frameworks =
>> strstr(developer_dir_path, "/SharedFrameworks/LLDB.framework");
>> if (shared_frameworks) {
>> - ::snprintf(shared_frameworks,
>> - sizeof(developer_dir_path) -
>> - (shared_frameworks - developer_dir_path),
>> - "/Developer");
>> + shared_frameworks[0] = '\0'; // truncate developer_dir_path at
>> this point
>> + strncat (developer_dir_path, "/Developer", sizeof
>> (developer_dir_path) - 1); // add /Developer on
>>developer_dir_path_valid = true;
>> } else {
>> - char *lib_priv_frameworks = strstr(
>> - developer_dir_path,
>> "/Library/PrivateFrameworks/LLDB.framework");
>> - if (lib_priv_frameworks) {
>> -*lib_priv_frameworks = '\0';
>> + // e.g.
>> /Applications/Xcode.app/Contents/Developer/Toolchains/iOS11.2.xctoolchain/System/Library/PrivateFrameworks/LLDB.framework
>> + char *developer_toolchains =
>> +strstr(developer_dir_path, "/Contents/Developer/Toolchains/");
>> + if (developer_toolchains) {
>> +developer_toolchains += sizeof ("/Contents/Developer") - 1;
>> +developer_toolchains[0] = '\0'; // truncate developer_dir_path
>> at this point
>> developer_dir_path_valid = true;
>>}
>> }
>>
>>
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r321271 - Work around test failures on red-hat linux
Yeah, purely renaming the variables would be a bit like hiding
problems under the carpet. But, I think adding the new test makes up
for that. This way, anyone who wants to fix this issue in the future
will have a simple test to validate his fix.
On 21 December 2017 at 14:55, Davide Italiano wrote:
> Thank you Pavel.
> I was really nervous about making this change but I agree it's for the best.
>
> Thanks,
>
> --
> Davide
>
> On Thu, Dec 21, 2017 at 3:40 PM, Pavel Labath via lldb-commits
> wrote:
>> Author: labath
>> Date: Thu Dec 21 06:40:03 2017
>> New Revision: 321271
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=321271&view=rev
>> Log:
>> Work around test failures on red-hat linux
>>
>> Two tests were failing because the debugger was picking up multiply
>> defined internal symbols from the system libraries. This is a bug, as
>> there should be no ambiguity because the tests are defining variables
>> with should shadow these symbols, but lldb is not smart enough to figure
>> that out.
>>
>> I work around the issue by renaming the variables in these tests, and in
>> exchange I create a self-contained test which reproduces the issue
>> without depending on the system libraries.
>>
>> This increases the predictability of our test suite.
>>
>> Modified:
>>
>> lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
>>
>> lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
>> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/main.cpp
>>
>> Modified:
>> lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py?rev=321271&r1=321270&r2=321271&view=diff
>> ==
>> ---
>> lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
>> (original)
>> +++
>> lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
>> Thu Dec 21 06:40:03 2017
>> @@ -42,7 +42,7 @@ class Radar9673644TestCase(TestBase):
>>
>> # rdar://problem/9673664 lldb expression evaluation problem
>>
>> -self.expect('expr char c[] = "foo"; c[0]',
>> +self.expect('expr char str[] = "foo"; str[0]',
>> substrs=["'f'"])
>> # runCmd: expr char c[] = "foo"; c[0]
>> # output: (char) $0 = 'f'
>>
>> Modified:
>> lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py?rev=321271&r1=321270&r2=321271&view=diff
>> ==
>> ---
>> lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
>> (original)
>> +++
>> lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
>> Thu Dec 21 06:40:03 2017
>> @@ -16,6 +16,13 @@ class TestConflictingSymbols(TestBase):
>> mydir = TestBase.compute_mydir(__file__)
>> NO_DEBUG_INFO_TESTCASE = True
>>
>> +def setUp(self):
>> +TestBase.setUp(self)
>> +
>> +self.One_line = line_number('One/One.c', '// break here')
>> +self.Two_line = line_number('Two/Two.c', '// break here')
>> +self.main_line = line_number('main.c', '// break here')
>> +
>> def test_conflicting_symbols(self):
>> self.build()
>> exe = os.path.join(os.getcwd(), "a.out")
>> @@ -27,15 +34,12 @@ class TestConflictingSymbols(TestBase):
>> environment = self.registerSharedLibrariesWithTarget(
>> target, ['One', 'Two'])
>>
>> -One_line = line_number('One/One.c', '// break here')
>> -Two_line = line_number('Two/Two.c', '// break here')
>> -main_line = line_number('main.c', '// break here')
>> lldbutil.run_break_set_command(
>> -self, 'breakpoint set -f One.c -l %s' % (One_line))
>> +self, 'breakpoint set -f One.c -l %s' % (self.One_line))
>> lldbutil.run_break_set_command(
>> -self, 'breakpoint set -f Two.c -l %s' % (Two_line))
>> +self, 'breakpoint set -f Two.c -l %s' % (self.Two_line))
>> lldbutil.run_break_set_by_file_and_line(
>> -self, 'main.c', main_line, num_expected_locations=1,
>> loc_exact=True)
>> +self, 'main.c', self.main_line, num_expected_locations=1,
>> loc_exact=True)
>>
>> process = target.LaunchSimple(
>> None, environment, self.get_process_working_directory())
>> @@ -88,3 +92,32 @@ class TestConflictingSymbols(TestBase):
>> error=True,
>> substrs=[
>>
Re: [Lldb-commits] [lldb] r321271 - Work around test failures on red-hat linux
What's the number of failures on Linux x86/64 red hat currently?
Thanks,
--
Davide
On Thu, Dec 21, 2017 at 4:09 PM, Pavel Labath wrote:
> Yeah, purely renaming the variables would be a bit like hiding
> problems under the carpet. But, I think adding the new test makes up
> for that. This way, anyone who wants to fix this issue in the future
> will have a simple test to validate his fix.
>
> On 21 December 2017 at 14:55, Davide Italiano wrote:
>> Thank you Pavel.
>> I was really nervous about making this change but I agree it's for the best.
>>
>> Thanks,
>>
>> --
>> Davide
>>
>> On Thu, Dec 21, 2017 at 3:40 PM, Pavel Labath via lldb-commits
>> wrote:
>>> Author: labath
>>> Date: Thu Dec 21 06:40:03 2017
>>> New Revision: 321271
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=321271&view=rev
>>> Log:
>>> Work around test failures on red-hat linux
>>>
>>> Two tests were failing because the debugger was picking up multiply
>>> defined internal symbols from the system libraries. This is a bug, as
>>> there should be no ambiguity because the tests are defining variables
>>> with should shadow these symbols, but lldb is not smart enough to figure
>>> that out.
>>>
>>> I work around the issue by renaming the variables in these tests, and in
>>> exchange I create a self-contained test which reproduces the issue
>>> without depending on the system libraries.
>>>
>>> This increases the predictability of our test suite.
>>>
>>> Modified:
>>>
>>> lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
>>>
>>> lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
>>> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/main.cpp
>>>
>>> Modified:
>>> lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py?rev=321271&r1=321270&r2=321271&view=diff
>>> ==
>>> ---
>>> lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
>>> (original)
>>> +++
>>> lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
>>> Thu Dec 21 06:40:03 2017
>>> @@ -42,7 +42,7 @@ class Radar9673644TestCase(TestBase):
>>>
>>> # rdar://problem/9673664 lldb expression evaluation problem
>>>
>>> -self.expect('expr char c[] = "foo"; c[0]',
>>> +self.expect('expr char str[] = "foo"; str[0]',
>>> substrs=["'f'"])
>>> # runCmd: expr char c[] = "foo"; c[0]
>>> # output: (char) $0 = 'f'
>>>
>>> Modified:
>>> lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py?rev=321271&r1=321270&r2=321271&view=diff
>>> ==
>>> ---
>>> lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
>>> (original)
>>> +++
>>> lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
>>> Thu Dec 21 06:40:03 2017
>>> @@ -16,6 +16,13 @@ class TestConflictingSymbols(TestBase):
>>> mydir = TestBase.compute_mydir(__file__)
>>> NO_DEBUG_INFO_TESTCASE = True
>>>
>>> +def setUp(self):
>>> +TestBase.setUp(self)
>>> +
>>> +self.One_line = line_number('One/One.c', '// break here')
>>> +self.Two_line = line_number('Two/Two.c', '// break here')
>>> +self.main_line = line_number('main.c', '// break here')
>>> +
>>> def test_conflicting_symbols(self):
>>> self.build()
>>> exe = os.path.join(os.getcwd(), "a.out")
>>> @@ -27,15 +34,12 @@ class TestConflictingSymbols(TestBase):
>>> environment = self.registerSharedLibrariesWithTarget(
>>> target, ['One', 'Two'])
>>>
>>> -One_line = line_number('One/One.c', '// break here')
>>> -Two_line = line_number('Two/Two.c', '// break here')
>>> -main_line = line_number('main.c', '// break here')
>>> lldbutil.run_break_set_command(
>>> -self, 'breakpoint set -f One.c -l %s' % (One_line))
>>> +self, 'breakpoint set -f One.c -l %s' % (self.One_line))
>>> lldbutil.run_break_set_command(
>>> -self, 'breakpoint set -f Two.c -l %s' % (Two_line))
>>> +self, 'breakpoint set -f Two.c -l %s' % (self.Two_line))
>>> lldbutil.run_break_set_by_file_and_line(
>>> -self, 'main.c', main_line, num_expected_locations=1,
>>> loc_exact=True)
>>> +self, 'main.c', self.main_line, num_expected_locations=1,
>>> loc_exact=T
Re: [Lldb-commits] [lldb] r321271 - Work around test failures on red-hat linux
Right now I'm looking at two (ignoring the debug-info multiplication):
TestExprs2.py and TestTopLevelExprs.py
TestExprs2 is encountering ambiguity when looking up the "environ"
symbol (the dynamic linker contains an extra copy). I think I know how
to handle that.
I haven't yet looked at what is the issue with the other test.
On 21 December 2017 at 15:11, Davide Italiano wrote:
> What's the number of failures on Linux x86/64 red hat currently?
>
> Thanks,
>
> --
> Davide
>
> On Thu, Dec 21, 2017 at 4:09 PM, Pavel Labath wrote:
>> Yeah, purely renaming the variables would be a bit like hiding
>> problems under the carpet. But, I think adding the new test makes up
>> for that. This way, anyone who wants to fix this issue in the future
>> will have a simple test to validate his fix.
>>
>> On 21 December 2017 at 14:55, Davide Italiano wrote:
>>> Thank you Pavel.
>>> I was really nervous about making this change but I agree it's for the best.
>>>
>>> Thanks,
>>>
>>> --
>>> Davide
>>>
>>> On Thu, Dec 21, 2017 at 3:40 PM, Pavel Labath via lldb-commits
>>> wrote:
Author: labath
Date: Thu Dec 21 06:40:03 2017
New Revision: 321271
URL: http://llvm.org/viewvc/llvm-project?rev=321271&view=rev
Log:
Work around test failures on red-hat linux
Two tests were failing because the debugger was picking up multiply
defined internal symbols from the system libraries. This is a bug, as
there should be no ambiguity because the tests are defining variables
with should shadow these symbols, but lldb is not smart enough to figure
that out.
I work around the issue by renaming the variables in these tests, and in
exchange I create a self-contained test which reproduces the issue
without depending on the system libraries.
This increases the predictability of our test suite.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/main.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py?rev=321271&r1=321270&r2=321271&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/radar_9673664/TestExprHelpExamples.py
Thu Dec 21 06:40:03 2017
@@ -42,7 +42,7 @@ class Radar9673644TestCase(TestBase):
# rdar://problem/9673664 lldb expression evaluation problem
-self.expect('expr char c[] = "foo"; c[0]',
+self.expect('expr char str[] = "foo"; str[0]',
substrs=["'f'"])
# runCmd: expr char c[] = "foo"; c[0]
# output: (char) $0 = 'f'
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py?rev=321271&r1=321270&r2=321271&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/c/conflicting-symbol/TestConflictingSymbol.py
Thu Dec 21 06:40:03 2017
@@ -16,6 +16,13 @@ class TestConflictingSymbols(TestBase):
mydir = TestBase.compute_mydir(__file__)
NO_DEBUG_INFO_TESTCASE = True
+def setUp(self):
+TestBase.setUp(self)
+
+self.One_line = line_number('One/One.c', '// break here')
+self.Two_line = line_number('Two/Two.c', '// break here')
+self.main_line = line_number('main.c', '// break here')
+
def test_conflicting_symbols(self):
self.build()
exe = os.path.join(os.getcwd(), "a.out")
@@ -27,15 +34,12 @@ class TestConflictingSymbols(TestBase):
environment = self.registerSharedLibrariesWithTarget(
target, ['One', 'Two'])
-One_line = line_number('One/One.c', '// break here')
-Two_line = line_number('Two/Two.c', '// break here')
-main_line = line_number('main.c', '// break here')
lldbutil.run_break_set_command(
-self, 'breakpoint set -f One.c -l %s' % (One_line))
Re: [Lldb-commits] [lldb] r321271 - Work around test failures on red-hat linux
On 21 December 2017 at 15:17, Pavel Labath wrote: > Right now I'm looking at two (ignoring the debug-info multiplication): > TestExprs2.py and TestTopLevelExprs.py > TestExprs2 is encountering ambiguity when looking up the "environ" > symbol (the dynamic linker contains an extra copy). I think I know how > to handle that. Ok, I take that back. I was hoping I could just implement ObjectFileELF::GetIsDynamicLinkEditor, but it seems that function is not actually called from anywhere. Does anyone have more background about that function? ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r321277 - Make one more test redhat-compatible
Author: labath
Date: Thu Dec 21 07:52:59 2017
New Revision: 321277
URL: http://llvm.org/viewvc/llvm-project?rev=321277&view=rev
Log:
Make one more test redhat-compatible
This test was also using "a" in an expression.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/top-level/test.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/top-level/test.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/top-level/test.cpp?rev=321277&r1=321276&r2=321277&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/top-level/test.cpp
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/top-level/test.cpp
Thu Dec 21 07:52:59 2017
@@ -42,11 +42,11 @@ public:
int i;
} s = { 15 };
-int as[4] = { 2, 3, 4, 5 };
+int numbers[4] = { 2, 3, 4, 5 };
-for (signed char a : as)
+for (signed char number: numbers)
{
-s.i -= a;
+s.i -= number;
}
return s.i;
@@ -94,14 +94,14 @@ public:
int doTest()
{
-int a = m.memberResult();
-a += MyClass::staticResult();
-a += m.externResult();
-a += MyEnum::myEnumThree;
-a += myEnumOne;
-a += AnotherClass().complicatedFunction();
-a += DiamondD(3).accessor();
-return a;
+int accumulator = m.memberResult();
+accumulator += MyClass::staticResult();
+accumulator += m.externResult();
+accumulator += MyEnum::myEnumThree;
+accumulator += myEnumOne;
+accumulator += AnotherClass().complicatedFunction();
+accumulator += DiamondD(3).accessor();
+return accumulator;
}
// --
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D41086: [lldb] Stop searching for a symbol in a pdb by regex
clayborg added a comment. Looks good! Repository: rL LLVM https://reviews.llvm.org/D41086 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r321271 - Work around test failures on red-hat linux
> On Dec 21, 2017, at 7:24 AM, Pavel Labath via lldb-commits > wrote: > > On 21 December 2017 at 15:17, Pavel Labath wrote: >> Right now I'm looking at two (ignoring the debug-info multiplication): >> TestExprs2.py and TestTopLevelExprs.py >> TestExprs2 is encountering ambiguity when looking up the "environ" >> symbol (the dynamic linker contains an extra copy). I think I know how >> to handle that. > > Ok, I take that back. I was hoping I could just implement > ObjectFileELF::GetIsDynamicLinkEditor, but it seems that function is > not actually called from anywhere. > > Does anyone have more background about that function? dyld on MacOS has exported functions like "malloc", and "free" and many many others that mirror libc function needed to bootstrap dyld before it has actually loaded libc into the process. When someone types "b malloc" on the lldb command line, we would end up setting breakpoints in both dyld and in libc which isn't what the user wanted. This flag is was used to say "this library defines many functions that are similar to other libraries, but no one wants to actually stop in these". This used to be used in: Platform::ModuleIsExcludedForUnconstrainedSearches(...) This is a function that says "for my platform, don't include this library in global searches. We eventually added ObjectFile::GetType() which can return ObjectFile::eTypeDynamicLinker. This is what is currently used in PlatformDarwin::ModuleIsExcludedForUnconstrainedSearches(...) to avoid dyld when doing global searches. So it might be as simple as making sure that the dynamic linker shared ObjectFile returns ObjectFile::eTypeDynamicLinker and then adding PlatformPosix::ModuleIsExcludedForUnconstrainedSearches(...) that does something similar to PlatformDarwin::ModuleIsExcludedForUnconstrainedSearches(...). > ___ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r321271 - Work around test failures on red-hat linux
BTW: we should remove the GetIsDynamicLinkEditor() from Module.h/cpp and ObjectFile.h, ObjectFileMachO.h/.cpp since it is dead code now. > On Dec 21, 2017, at 7:24 AM, Pavel Labath via lldb-commits > wrote: > > On 21 December 2017 at 15:17, Pavel Labath wrote: >> Right now I'm looking at two (ignoring the debug-info multiplication): >> TestExprs2.py and TestTopLevelExprs.py >> TestExprs2 is encountering ambiguity when looking up the "environ" >> symbol (the dynamic linker contains an extra copy). I think I know how >> to handle that. > > Ok, I take that back. I was hoping I could just implement > ObjectFileELF::GetIsDynamicLinkEditor, but it seems that function is > not actually called from anywhere. > > Does anyone have more background about that function? > ___ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r320240 - Update PlatformDarwin::GetDeveloperDir to handle the two
Yeah I need to see if I can write a unit test instantiating the platform and
changing the values that HostInfo::GetLLDBPath returns to synthetic values, but
I haven’t had time to look at that yet.
> On Dec 21, 2017, at 7:01 AM, Davide Italiano via lldb-commits
> wrote:
>
> Jason, any chance we can write a test case for this?
>
> --
> Davide
>
>> On Mon, Dec 11, 2017 at 12:52 AM, Davide Italiano
>> wrote:
>> Testcase?
>>
>> On Fri, Dec 8, 2017 at 7:06 PM, Jason Molenda via lldb-commits
>> wrote:
>>> Author: jmolenda
>>> Date: Fri Dec 8 19:06:19 2017
>>> New Revision: 320240
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=320240&view=rev
>>> Log:
>>> Update PlatformDarwin::GetDeveloperDir to handle the two
>>> most common cases where the Xcode.app bundle puts lldb -
>>> either as a default part of the bundle, or in a toolchain
>>> subdirectory, so the platform subclasses can find files
>>> relative to this directory.
>>>
>>> Dropped support for handling the case where the lldb
>>> framework was in /Library/PrivateFrameworks. I think
>>> this was intended to handle the case where lldb is installed
>>> in / (outside the Xcode.app bundle) - but in that case, we
>>> can look in the raw directory file paths to find anything.
>>>
>>>
>>>
>>> Modified:
>>>lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
>>>
>>> Modified: lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp?rev=320240&r1=320239&r2=320240&view=diff
>>> ==
>>> --- lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp (original)
>>> +++ lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp Fri Dec 8
>>> 19:06:19 2017
>>> @@ -1132,28 +1132,33 @@ bool PlatformDarwin::ARMGetSupportedArch
>>> return false;
>>> }
>>>
>>> +// Return a directory path like /Applications/Xcode.app/Contents/Developer
>>> const char *PlatformDarwin::GetDeveloperDirectory() {
>>> std::lock_guard guard(m_mutex);
>>> if (m_developer_directory.empty()) {
>>> bool developer_dir_path_valid = false;
>>> char developer_dir_path[PATH_MAX];
>>> FileSpec temp_file_spec;
>>> +
>>> +// Get the lldb framework's file path, and if it exists, truncate some
>>> +// components to only the developer directory path.
>>> if (HostInfo::GetLLDBPath(ePathTypeLLDBShlibDir, temp_file_spec)) {
>>> if (temp_file_spec.GetPath(developer_dir_path,
>>> sizeof(developer_dir_path))) {
>>> +// e.g.
>>> /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework
>>> char *shared_frameworks =
>>> strstr(developer_dir_path, "/SharedFrameworks/LLDB.framework");
>>> if (shared_frameworks) {
>>> - ::snprintf(shared_frameworks,
>>> - sizeof(developer_dir_path) -
>>> - (shared_frameworks - developer_dir_path),
>>> - "/Developer");
>>> + shared_frameworks[0] = '\0'; // truncate developer_dir_path at
>>> this point
>>> + strncat (developer_dir_path, "/Developer", sizeof
>>> (developer_dir_path) - 1); // add /Developer on
>>> developer_dir_path_valid = true;
>>> } else {
>>> - char *lib_priv_frameworks = strstr(
>>> - developer_dir_path,
>>> "/Library/PrivateFrameworks/LLDB.framework");
>>> - if (lib_priv_frameworks) {
>>> -*lib_priv_frameworks = '\0';
>>> + // e.g.
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/iOS11.2.xctoolchain/System/Library/PrivateFrameworks/LLDB.framework
>>> + char *developer_toolchains =
>>> +strstr(developer_dir_path, "/Contents/Developer/Toolchains/");
>>> + if (developer_toolchains) {
>>> +developer_toolchains += sizeof ("/Contents/Developer") - 1;
>>> +developer_toolchains[0] = '\0'; // truncate developer_dir_path
>>> at this point
>>> developer_dir_path_valid = true;
>>> }
>>> }
>>>
>>>
>>> ___
>>> lldb-commits mailing list
>>> lldb-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r320240 - Update PlatformDarwin::GetDeveloperDir to handle the two
No worries! Do you want me to assign a PR/radar to you?
Thanks!
--
Davide
On Thu, Dec 21, 2017 at 5:41 PM, Jason Molenda wrote:
> Yeah I need to see if I can write a unit test instantiating the platform and
> changing the values that HostInfo::GetLLDBPath returns to synthetic values,
> but I haven’t had time to look at that yet.
>
>> On Dec 21, 2017, at 7:01 AM, Davide Italiano via lldb-commits
>> wrote:
>>
>> Jason, any chance we can write a test case for this?
>>
>> --
>> Davide
>>
>>> On Mon, Dec 11, 2017 at 12:52 AM, Davide Italiano
>>> wrote:
>>> Testcase?
>>>
>>> On Fri, Dec 8, 2017 at 7:06 PM, Jason Molenda via lldb-commits
>>> wrote:
Author: jmolenda
Date: Fri Dec 8 19:06:19 2017
New Revision: 320240
URL: http://llvm.org/viewvc/llvm-project?rev=320240&view=rev
Log:
Update PlatformDarwin::GetDeveloperDir to handle the two
most common cases where the Xcode.app bundle puts lldb -
either as a default part of the bundle, or in a toolchain
subdirectory, so the platform subclasses can find files
relative to this directory.
Dropped support for handling the case where the lldb
framework was in /Library/PrivateFrameworks. I think
this was intended to handle the case where lldb is installed
in / (outside the Xcode.app bundle) - but in that case, we
can look in the raw directory file paths to find anything.
Modified:
lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
Modified: lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp?rev=320240&r1=320239&r2=320240&view=diff
==
--- lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp (original)
+++ lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp Fri Dec
8 19:06:19 2017
@@ -1132,28 +1132,33 @@ bool PlatformDarwin::ARMGetSupportedArch
return false;
}
+// Return a directory path like /Applications/Xcode.app/Contents/Developer
const char *PlatformDarwin::GetDeveloperDirectory() {
std::lock_guard guard(m_mutex);
if (m_developer_directory.empty()) {
bool developer_dir_path_valid = false;
char developer_dir_path[PATH_MAX];
FileSpec temp_file_spec;
+
+// Get the lldb framework's file path, and if it exists, truncate some
+// components to only the developer directory path.
if (HostInfo::GetLLDBPath(ePathTypeLLDBShlibDir, temp_file_spec)) {
if (temp_file_spec.GetPath(developer_dir_path,
sizeof(developer_dir_path))) {
+// e.g.
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework
char *shared_frameworks =
strstr(developer_dir_path, "/SharedFrameworks/LLDB.framework");
if (shared_frameworks) {
- ::snprintf(shared_frameworks,
- sizeof(developer_dir_path) -
- (shared_frameworks - developer_dir_path),
- "/Developer");
+ shared_frameworks[0] = '\0'; // truncate developer_dir_path at
this point
+ strncat (developer_dir_path, "/Developer", sizeof
(developer_dir_path) - 1); // add /Developer on
developer_dir_path_valid = true;
} else {
- char *lib_priv_frameworks = strstr(
- developer_dir_path,
"/Library/PrivateFrameworks/LLDB.framework");
- if (lib_priv_frameworks) {
-*lib_priv_frameworks = '\0';
+ // e.g.
/Applications/Xcode.app/Contents/Developer/Toolchains/iOS11.2.xctoolchain/System/Library/PrivateFrameworks/LLDB.framework
+ char *developer_toolchains =
+strstr(developer_dir_path, "/Contents/Developer/Toolchains/");
+ if (developer_toolchains) {
+developer_toolchains += sizeof ("/Contents/Developer") - 1;
+developer_toolchains[0] = '\0'; // truncate
developer_dir_path at this point
developer_dir_path_valid = true;
}
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D41352: debugserver: Propagate environment in launch-mode (pr35671)
labath updated this revision to Diff 127898.
labath added a comment.
Add PushEnvironmentIfNeeded to avoid creating duplicate entries in the
environment.
https://reviews.llvm.org/D41352
Files:
tools/debugserver/source/RNBContext.cpp
tools/debugserver/source/RNBContext.h
tools/debugserver/source/debugserver.cpp
unittests/tools/lldb-server/CMakeLists.txt
unittests/tools/lldb-server/tests/LLGSTest.cpp
unittests/tools/lldb-server/tests/TestClient.cpp
unittests/tools/lldb-server/tests/TestClient.h
Index: unittests/tools/lldb-server/tests/TestClient.h
===
--- unittests/tools/lldb-server/tests/TestClient.h
+++ unittests/tools/lldb-server/tests/TestClient.h
@@ -21,12 +21,20 @@
#include
#include
+#if LLDB_SERVER_IS_DEBUGSERVER
+#define LLGS_TEST(x) DISABLED_ ## x
+#define DS_TEST(x) x
+#else
+#define LLGS_TEST(x) x
+#define DS_TEST(x) DISABLED_ ## x
+#endif
+
namespace llgs_tests {
class TestClient
: public lldb_private::process_gdb_remote::GDBRemoteCommunicationClient {
public:
- static bool IsDebugServer();
- static bool IsLldbServer();
+ static bool IsDebugServer() { return LLDB_SERVER_IS_DEBUGSERVER; }
+ static bool IsLldbServer() { return !IsDebugServer(); }
/// Launches the server, connects it to the client and returns the client. If
/// Log is non-empty, the server will write it's log to this file.
@@ -37,6 +45,13 @@
static llvm::Expected>
launch(llvm::StringRef Log, llvm::ArrayRef InferiorArgs);
+ /// Allows user to pass additional arguments to the server. Be careful when
+ /// using this for generic tests, as the two stubs have different
+ /// command-line interfaces.
+ static llvm::Expected>
+ launchCustom(llvm::StringRef Log, llvm::ArrayRef ServerArgs, llvm::ArrayRef InferiorArgs);
+
+
~TestClient() override;
llvm::Error SetInferior(llvm::ArrayRef inferior_args);
llvm::Error ListThreadsInStopReply();
Index: unittests/tools/lldb-server/tests/TestClient.cpp
===
--- unittests/tools/lldb-server/tests/TestClient.cpp
+++ unittests/tools/lldb-server/tests/TestClient.cpp
@@ -27,11 +27,6 @@
using namespace llvm;
namespace llgs_tests {
-bool TestClient::IsDebugServer() {
- return sys::path::filename(LLDB_SERVER).contains("debugserver");
-}
-
-bool TestClient::IsLldbServer() { return !IsDebugServer(); }
TestClient::TestClient(std::unique_ptr Conn) {
SetConnection(Conn.release());
@@ -56,6 +51,10 @@
}
Expected> TestClient::launch(StringRef Log, ArrayRef InferiorArgs) {
+ return launchCustom(Log, {}, InferiorArgs);
+}
+
+Expected> TestClient::launchCustom(StringRef Log, ArrayRef ServerArgs, ArrayRef InferiorArgs) {
const ArchSpec &arch_spec = HostInfo::GetArchitecture();
Args args;
args.AppendArgument(LLDB_SERVER);
@@ -80,6 +79,9 @@
args.AppendArgument(
("localhost:" + Twine(listen_socket.GetLocalPortNumber())).str());
+ for (StringRef arg : ServerArgs)
+args.AppendArgument(arg);
+
if (!InferiorArgs.empty()) {
args.AppendArgument("--");
for (StringRef arg : InferiorArgs)
Index: unittests/tools/lldb-server/tests/LLGSTest.cpp
===
--- unittests/tools/lldb-server/tests/LLGSTest.cpp
+++ unittests/tools/lldb-server/tests/LLGSTest.cpp
@@ -16,11 +16,6 @@
using namespace llvm;
TEST_F(TestBase, LaunchModePreservesEnvironment) {
- if (TestClient::IsDebugServer()) {
-GTEST_LOG_(WARNING) << "Test fails with debugserver: llvm.org/pr35671";
-return;
- }
-
putenv(const_cast("LLDB_TEST_MAGIC_VARIABLE=LLDB_TEST_MAGIC_VALUE"));
auto ClientOr = TestClient::launch(getLogFileName(),
@@ -34,3 +29,20 @@
HasValue(testing::Property(&StopReply::getKind,
WaitStatus{WaitStatus::Exit, 0})));
}
+
+TEST_F(TestBase, DS_TEST(DebugserverEnv)) {
+ // Test that --env takes precedence over inherited environment variables.
+ putenv(const_cast("LLDB_TEST_MAGIC_VARIABLE=foobar"));
+
+ auto ClientOr = TestClient::launchCustom(getLogFileName(),
+ { "--env", "LLDB_TEST_MAGIC_VARIABLE=LLDB_TEST_MAGIC_VALUE" },
+ {getInferiorPath("environment_check")});
+ ASSERT_THAT_EXPECTED(ClientOr, Succeeded());
+ auto &Client = **ClientOr;
+
+ ASSERT_THAT_ERROR(Client.ContinueAll(), Succeeded());
+ ASSERT_THAT_EXPECTED(
+ Client.GetLatestStopReplyAs(),
+ HasValue(testing::Property(&StopReply::getKind,
+ WaitStatus{WaitStatus::Exit, 0})));
+}
Index: unittests/tools/lldb-server/CMakeLists.txt
===
--- unittests/tools/lldb-server/CMakeLists.txt
+++ unittests/tools/lldb-server/CMakeLists.txt
@@ -13,9 +13,9 @@
add_lldb_test_executable(environment_check inferior/environment_check.cpp)
if (CMAKE_SYSTEM_NAME MATCHES "Darwin")
- add_definitions(-DLLDB_SERVE
Re: [Lldb-commits] [lldb] r321271 - Work around test failures on red-hat linux
That's great, thanks for the explanation. I'll look into that. On 21 December 2017 at 16:34, Greg Clayton wrote: > > On Dec 21, 2017, at 7:24 AM, Pavel Labath via lldb-commits > wrote: > > On 21 December 2017 at 15:17, Pavel Labath wrote: > > Right now I'm looking at two (ignoring the debug-info multiplication): > TestExprs2.py and TestTopLevelExprs.py > TestExprs2 is encountering ambiguity when looking up the "environ" > symbol (the dynamic linker contains an extra copy). I think I know how > to handle that. > > > Ok, I take that back. I was hoping I could just implement > ObjectFileELF::GetIsDynamicLinkEditor, but it seems that function is > not actually called from anywhere. > > Does anyone have more background about that function? > > > dyld on MacOS has exported functions like "malloc", and "free" and many many > others that mirror libc function needed to bootstrap dyld before it has > actually loaded libc into the process. When someone types "b malloc" on the > lldb command line, we would end up setting breakpoints in both dyld and in > libc which isn't what the user wanted. This flag is was used to say "this > library defines many functions that are similar to other libraries, but no > one wants to actually stop in these". This used to be used in: > > Platform::ModuleIsExcludedForUnconstrainedSearches(...) > > This is a function that says "for my platform, don't include this library in > global searches. We eventually added ObjectFile::GetType() which can return > ObjectFile::eTypeDynamicLinker. This is what is currently used in > PlatformDarwin::ModuleIsExcludedForUnconstrainedSearches(...) to avoid dyld > when doing global searches. > > So it might be as simple as making sure that the dynamic linker shared > ObjectFile returns ObjectFile::eTypeDynamicLinker and then adding > PlatformPosix::ModuleIsExcludedForUnconstrainedSearches(...) that does > something similar to > PlatformDarwin::ModuleIsExcludedForUnconstrainedSearches(...). > > > > ___ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D41352: debugserver: Propagate environment in launch-mode (pr35671)
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. Thanks for all the revisions. Looks good. https://reviews.llvm.org/D41352 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D41427: [lldb] Fix crash when parsing the type of a function without any arguments
asmith added a comment. This fix is part of a larger set of changes to retrieve the type for a function signature and I don't see how to test for this without those changes. With all the other changes, lldb-test fails without this fix and passes with it. So it's implicitly already tested. Repository: rL LLVM https://reviews.llvm.org/D41427 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r321322 - Bring clang options in error messages up to date.
Author: adrian
Date: Thu Dec 21 15:04:51 2017
New Revision: 321322
URL: http://llvm.org/viewvc/llvm-project?rev=321322&view=rev
Log:
Bring clang options in error messages up to date.
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp?rev=321322&r1=321321&r2=321322&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
(original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp Thu Dec
21 15:04:51 2017
@@ -1743,8 +1743,8 @@ TypeSP DWARFASTParserClang::ParseTypeFro
"DWARF DW_TAG_array_type DIE at 0x%8.8x has a "
"class/union/struct element type DIE 0x%8.8x that is a "
"forward declaration, not a complete definition.\nTry "
- "compiling the source file with -fno-limit-debug-info or
"
- "disable -gmodule",
+ "compiling the source file with -fstandalone-debug or "
+ "disable -gmodules",
die.GetOffset(), type_die_ref.die_offset);
else
module_sp->ReportError(
@@ -2255,7 +2255,7 @@ bool DWARFASTParserClang::CompleteTypeFr
if (die.GetCU()->GetProducer() ==
DWARFCompileUnit::eProducerClang)
module->ReportError(":: Try compiling the source file with "
- "-fno-limit-debug-info.");
+ "-fstandalone-debug.");
// We have no choice other than to pretend that the base class
// is complete. If we don't do this, clang will crash when we
@@ -3095,7 +3095,7 @@ bool DWARFASTParserClang::ParseChildMemb
"DWARF DIE at 0x%8.8x (class %s) has a member variable "
"0x%8.8x (%s) whose type is a forward declaration, not a
"
"complete definition.\nTry compiling the source file "
- "with -fno-limit-debug-info",
+ "with -fstandalone-debug",
parent_die.GetOffset(), parent_die.GetName(),
die.GetOffset(), name);
else
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D41427: [lldb] Fix crash when parsing the type of a function without any arguments
lldb-test doesn’t actually exercise any of this. It’s a pretty new addition and doesn’t even support pdb yet as far as I know. So when you say it fails without the other changes, but passes with this, I think you must be talking about some test that runs via check-lldb, or some unittest. To be clear, I’m talking about the executable lldb-test.exe, which was recently introduced as a way to run FileCheck tests. I was thinking you could add a flag to it and call it as lldb-test.exe symbol -functions foo.exe And have it just print function signatures and FileCheck the output for a function you’ve written that takes no arguments. That should crash without this patch but succeed with this patch alone right? Since lldb-test is a tool whose sole purpose is printing stuff for testing purposes, the format isn’t too important, the important thing is just that it provides a really easy avenue for exercising this code. LMK if this makes sense On Thu, Dec 21, 2017 at 1:53 PM Aaron Smith via Phabricator < revi...@reviews.llvm.org> wrote: > asmith added a comment. > > This fix is part of a larger set of changes to retrieve the type for a > function signature and I don't see how to test for this without those > changes. With all the other changes, lldb-test fails without this fix and > passes with it. So it's implicitly already tested. > > > Repository: > rL LLVM > > https://reviews.llvm.org/D41427 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r321328 - Change the default Aarch64 ISA to be v8.2 to correctly decode newer
Author: jmolenda
Date: Thu Dec 21 16:16:04 2017
New Revision: 321328
URL: http://llvm.org/viewvc/llvm-project?rev=321328&view=rev
Log:
Change the default Aarch64 ISA to be v8.2 to correctly decode newer
instructions (e.g. on the new iphones).
Modified:
lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
Modified: lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp?rev=321328&r1=321327&r2=321328&view=diff
==
--- lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp (original)
+++ lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp Thu Dec
21 16:16:04 2017
@@ -1127,6 +1127,11 @@ DisassemblerLLVMC::DisassemblerLLVMC(con
features_str += "+dspr2,";
}
+ // If any AArch64 variant, enable the ARMv8.2 ISA
+ // extensions so we can disassemble newer instructions.
+ if (triple.getArch() == llvm::Triple::aarch64)
+features_str += "+v8.2a";
+
m_disasm_ap.reset(new LLVMCDisassembler(triple_str, cpu,
features_str.c_str(),
flavor, *this));
if (!m_disasm_ap->IsValid()) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r321338 - Change SBProcess::ReadCStringFromMemory() back to returning
Author: jmolenda
Date: Thu Dec 21 19:27:02 2017
New Revision: 321338
URL: http://llvm.org/viewvc/llvm-project?rev=321338&view=rev
Log:
Change SBProcess::ReadCStringFromMemory() back to returning
an empty Python string object when it reads a 0-length
string out of memory (and a successful SBError object).
Added:
lldb/trunk/packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/
lldb/trunk/packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/Makefile
lldb/trunk/packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/TestReadMemCString.py
lldb/trunk/packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/main.c
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/TestMiniDumpNew.py
lldb/trunk/scripts/Python/python-typemaps.swig
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/TestMiniDumpNew.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/TestMiniDumpNew.py?rev=321338&r1=321337&r2=321338&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/TestMiniDumpNew.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/TestMiniDumpNew.py
Thu Dec 21 19:27:02 2017
@@ -117,7 +117,7 @@ class MiniDumpNewTestCase(TestBase):
thread = self.process.GetThreadAtIndex(0)
self.assertEqual(thread.GetStopReason(), lldb.eStopReasonNone)
stop_description = thread.GetStopDescription(256)
-self.assertEqual(stop_description, None)
+self.assertEqual(stop_description, "")
def do_test_deeper_stack(self, binary, core, pid):
target = self.dbg.CreateTarget(binary)
Added:
lldb/trunk/packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/Makefile
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/Makefile?rev=321338&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/Makefile
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/Makefile
Thu Dec 21 19:27:02 2017
@@ -0,0 +1,6 @@
+LEVEL = ../../../make
+
+C_SOURCES := main.c
+EXE := read-mem-cstring
+
+include $(LEVEL)/Makefile.rules
Added:
lldb/trunk/packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/TestReadMemCString.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/TestReadMemCString.py?rev=321338&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/TestReadMemCString.py
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/python_api/process/read-mem-cstring/TestReadMemCString.py
Thu Dec 21 19:27:02 2017
@@ -0,0 +1,62 @@
+"""Test reading c-strings from memory via SB API."""
+
+from __future__ import print_function
+
+import os
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestReadMemCString(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+TestBase.setUp(self)
+
+# Need to have a char* pointer that points to unmapped memory to run
+# this test on other platforms -- Darwin only for now.
+@skipUnlessDarwin
+def test_read_memory_c_string(self):
+"""Test corner case behavior of SBProcess::ReadCStringFromMemory"""
+self.build()
+ self.dbg.SetAsync(False)
+
+self.main_source = "main.c"
+ self.main_source_spec = lldb.SBFileSpec(self.main_source)
+ self.exe = os.path.join(os.getcwd(), "read-mem-cstring")
+
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, 'breakpoint here', self.main_source_spec, None, self.exe)
+
+ frame = thread.GetFrameAtIndex(0)
+
+err = lldb.SBError()
+
+empty_str_addr =
frame.FindVariable("empty_string").GetValueAsUnsigned(err)
+self.assertTrue(err.Success())
+self.assertTrue(empty_str_addr != lldb.LLDB_INVALID_ADDRESS)
+
+one_letter_str_addr =
frame.FindVariable("one_letter_string").GetValueAsUnsigned(err)
+self.assertTrue(err.Success())
+self.assertTrue(one_letter_str_addr != lldb.LLDB_INVALID_ADDRESS)
+
+invalid_memory_str_addr =
frame.FindVariable("invalid_memory_string").GetValueAsUnsigned(err)
+self.assertTrue(err.Success())
+self.assertTrue(invalid_memory_str_addr != lldb.LLDB_INVALID_ADDRESS)
+
+# Important: An empty
