[Lldb-commits] [lldb] r347391 - Revert 347365, its prerequisite 347364 got reverted.
Author: nico
Date: Wed Nov 21 04:50:13 2018
New Revision: 347391
URL: http://llvm.org/viewvc/llvm-project?rev=347391&view=rev
Log:
Revert 347365, its prerequisite 347364 got reverted.
Modified:
lldb/trunk/source/Symbol/ClangASTContext.cpp
Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=347391&r1=347390&r2=347391&view=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Wed Nov 21 04:50:13 2018
@@ -5963,10 +5963,10 @@ GetObjCFieldAtIndex(clang::ASTContext *a
if (is_bitfield && ast) {
clang::Expr *bitfield_bit_size_expr = ivar_pos->getBitWidth();
- clang::Expr::EvalResult result;
+ llvm::APSInt bitfield_apsint;
if (bitfield_bit_size_expr &&
- bitfield_bit_size_expr->EvaluateAsInt(result, *ast)) {
-llvm::APSInt bitfield_apsint = result.Val.getInt();
+ bitfield_bit_size_expr->EvaluateAsInt(bitfield_apsint,
+*ast)) {
*bitfield_bit_size_ptr = bitfield_apsint.getLimitedValue();
}
}
@@ -6023,11 +6023,10 @@ CompilerType ClangASTContext::GetFieldAt
if (is_bitfield) {
clang::Expr *bitfield_bit_size_expr = field->getBitWidth();
- clang::Expr::EvalResult result;
+ llvm::APSInt bitfield_apsint;
if (bitfield_bit_size_expr &&
- bitfield_bit_size_expr->EvaluateAsInt(result,
+ bitfield_bit_size_expr->EvaluateAsInt(bitfield_apsint,
*getASTContext())) {
-llvm::APSInt bitfield_apsint = result.Val.getInt();
*bitfield_bit_size_ptr = bitfield_apsint.getLimitedValue();
}
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54731: [lit] Enable the use of custom user-defined lit commands
labath added a comment. I think that something like this would go a long way towards solving the problems with lit tests we're having in lldb. However, the part that is not clear to me is whether it is actually necessary to modify lit (shtest) to achieve this. It seems to me an equivalent effect to the command from the motivating example could be achieved via something like RUN: %compile --source=%p/Inputs/foo.cpp --mode=debug --opt=none --link=no --output=%t.o --clean=yes where `%compile` expands to a python script living somewhere in the lldb repository. This script could do the same thing that the implementation of `COMPILE: ` would do, except it would be done in a separate process. The only downside of that I see is the extra process will incur some overhead, slowing down the testing, but I am not sure if we care about that (or if it would even be measurable). OTOH, the benefits are: - decreased complexity of lit - decreased level of surprise of developers seeing new lit commands - easier reproducibility of tests when debugging (just copy paste the `%compile` run-line to rebuild the executable) https://reviews.llvm.org/D54731 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file
aleksandr.urakov updated this revision to Diff 174916.
aleksandr.urakov added a comment.
Update the patch, move symtab finalization back to object files.
This patch makes object files and symbol files (in the case if they add symbols
in a symtab) to be responsible for finalization of a symtab. It's because a
symtab is used in a bunch of places, where it's undesirable to retrieve one
through a symbol vendor. For example, when the object file itself uses its
symtab, we can't retrieve it from the symbol vendor, because the symbol vendor
is implemented in the terms of an object file, so such a solution will
introduce a circular dependency, which is undesirable.
But on the other hand, if the object file uses its own symtab, then it likely
doesn't rely on presence of symbols from the symbol file in that symtab. The
only things it requires are symbols from the object file and finalization of
the symtab.
So after this update we have the following guarantees:
- if a symtab is retrieved from an object file, then it's consistent and
guaranteed contains symbols from the object file. It may (or may not) also
contain symbols from a symbol file;
- if a symtab is retrieved from a symbol vendor, then it's consistent and
guaranteed contains symbols from an object file and a symbol file.
I've taken a look at the places, where the symtab is retrieved from an object
file, and it seems that the only place we need to fix due to that guarantees is
the preventive usage of the symbol vendor in the `Address::GetAddressClass`
function.
The disadvantages of the current solution are:
- when symbols are added in the symtab both from an object file and a symbol
file, the symtab is finalized twice;
- the symtabs retrieved from different places have different guarantees.
But to solve these we need to make some other more higher-level entity (besides
the object file) to own the symtab (e.g. symbol vendor) and to rewrite all the
related things in object files and symbol files. The problem is that it's not
trivial to make it and not to break a lot of current code.
What do you think about this approach?
https://reviews.llvm.org/D53368
Files:
include/lldb/Symbol/SymbolFile.h
include/lldb/Symbol/SymbolVendor.h
source/Core/Address.cpp
source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
source/Symbol/SymbolVendor.cpp
unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp
Index: unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp
===
--- unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp
+++ unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp
@@ -620,3 +620,20 @@
EXPECT_EQ(0u, num_results);
EXPECT_EQ(0u, results.GetSize());
}
+
+TEST_F(SymbolFilePDBTests, TestFindSymbolsWithNameAndType) {
+ FileSpec fspec(m_pdb_test_exe.c_str());
+ ArchSpec aspec("i686-pc-windows");
+ lldb::ModuleSP module = std::make_shared(fspec, aspec);
+
+ SymbolContextList sc_list;
+ EXPECT_EQ(1u,
+module->FindSymbolsWithNameAndType(ConstString("?foo@@YAHH@Z"),
+ lldb::eSymbolTypeAny, sc_list));
+ EXPECT_EQ(1u, sc_list.GetSize());
+
+ SymbolContext sc;
+ EXPECT_TRUE(sc_list.GetContextAtIndex(0, sc));
+ EXPECT_STREQ("int foo(int)",
+ sc.GetFunctionName(Mangled::ePreferDemangled).AsCString());
+}
Index: source/Symbol/SymbolVendor.cpp
===
--- source/Symbol/SymbolVendor.cpp
+++ source/Symbol/SymbolVendor.cpp
@@ -57,7 +57,7 @@
//--
SymbolVendor::SymbolVendor(const lldb::ModuleSP &module_sp)
: ModuleChild(module_sp), m_type_list(), m_compile_units(),
- m_sym_file_ap() {}
+ m_sym_file_ap(), m_symtab() {}
//--
// Destructor
@@ -434,14 +434,23 @@
Symtab *SymbolVendor::GetSymtab() {
ModuleSP module_sp(GetModule());
- if (module_sp) {
-ObjectFile *objfile = module_sp->GetObjectFile();
-if (objfile) {
- // Get symbol table from unified section list.
- return objfile->GetSymtab();
-}
- }
- return nullptr;
+ if (!module_sp)
+return nullptr;
+
+ std::lock_guard guard(module_sp->GetMutex());
+
+ if (m_symtab)
+return m_symtab;
+
+ ObjectFile *objfile = module_sp->GetObjectFile();
+ if (!objfile)
+return nullptr;
+
+ m_symtab = objfile->GetSymtab();
+ if (m_symtab && m_sym_file_ap)
+m_sym_file_ap->AddSymbols(*m_symtab);
+
+ return m_symtab;
}
void SymbolVendor::ClearSymtab() {
Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
@@ -136,6 +136,8 @@
const std::string &scope_qualified_name,
std::vector &mangled_names) overr
[Lldb-commits] [PATCH] D53759: [PDB] Support PDB-backed expressions evaluation
aleksandr.urakov added a comment. Ping! Can someone to have a look as well? https://reviews.llvm.org/D53759 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54731: [lit] Enable the use of custom user-defined lit commands
zturner added a comment.
In https://reviews.llvm.org/D54731#1305183, @labath wrote:
> I think that something like this would go a long way towards solving the
> problems with lit tests we're having in lldb.
>
> However, the part that is not clear to me is whether it is actually necessary
> to modify lit (shtest) to achieve this. It seems to me an equivalent effect
> to the command from the motivating example could be achieved via something
> like
>
> RUN: %compile --source=%p/Inputs/foo.cpp --mode=debug --opt=none --link=no
> --output=%t.o --clean=yes
>
>
> where `%compile` expands to a python script living somewhere in the lldb
> repository. This script could do the same thing that the implementation of
> `COMPILE: ` would do, except it would be done in a separate process.
>
> The only downside of that I see is the extra process will incur some
> overhead, slowing down the testing, but I am not sure if we care about that
> (or if it would even be measurable). OTOH, the benefits are:
>
> - decreased complexity of lit
> - decreased level of surprise of developers seeing new lit commands
> - easier reproducibility of tests when debugging (just copy paste the
> `%compile` run-line to rebuild the executable)
I did consider this, and I'm still open to the possibility of doing things this
way. Two reasons I chose this route instead are:
1. We have a lot of setup that runs in lit before we ever get to this point,
and a builder could re-use this. For example, the environment, any additional
lit configuration parameters specified on the command line, etc. We could of
course pass these in to the `compile.py` script via hidden arguments, so this
isn't a total blocker, it was just something I thought of.
2. We could re-purpose this machinery for other uses. For example, I could
imagine re-writing many lldb inline tests in terms of a custom command prefix.
For example, here's `test/functionalities/data-formatter/dump_dynamic/main.cpp`:
class Base {
public:
Base () = default;
virtual int func() { return 1; }
virtual ~Base() = default;
};
class Derived : public Base {
private:
int m_derived_data;
public:
Derived () : Base(), m_derived_data(0x0fedbeef) {}
virtual ~Derived() = default;
virtual int func() { return m_derived_data; }
};
int main (int argc, char const *argv[])
{
Base *base = new Derived();
return 0; //% stream = lldb.SBStream()
//% base = self.frame().FindVariable("base")
//% base.SetPreferDynamicValue(lldb.eDynamicDontRunTarget)
//% base.GetDescription(stream)
//% if self.TraceOn(): print(stream.GetData())
//% self.assertTrue(stream.GetData().startswith("(Derived *"))
}
I could imagine writing this as:
class Base {
public:
Base () = default;
virtual int func() { return 1; }
virtual ~Base() = default;
};
class Derived : public Base {
private:
int m_derived_data;
public:
Derived () : Base(), m_derived_data(0x0fedbeef) {}
virtual ~Derived() = default;
virtual int func() { return m_derived_data; }
};
int main (int argc, char const *argv[])
{
Base *base = new Derived();
return 0;
}
//SCRIPT: stream = lldb.SBStream()
//SCRIPT: base = self.frame().FindVariable("base")
//SCRIPT: base.SetPreferDynamicValue(lldb.eDynamicDontRunTarget)
//SCRIPT: base.GetDescription(stream)
//EXPECT: stream.GetData().startswith("(Derived *"))
where the `lldb` module is loaded in-process similar to how it is with
`dotest.py`. (I do wonder if all `lldbinline` tests could actually be
convereted to lit / FileCheck tests right now, today, using an lldbinit file
such as:
script stream = lldb.SBStream()
script base = self.frame().FindVariable("base")
script base.SetPreferDynamicValue(lldb.eDynamicDontRunTarget)
script base.GetDescription(stream)
script stream.GetData()
and then FileCheck'ing that, but I haven't tried and I haven't investigated
every single lldbinline test to see if they would all fit into this model.
In any case, the point being that being able to run python code in-process
opens up a lot of interesting possibilities, considering that's how all the
dotest tests are written. Whether we need that flexibility is open for
discussion though. Like I said, i'm willing to give the external script a try
if people think we should try a more conservative approach first.
https://reviews.llvm.org/D54731
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54808: [lit] Add pthread to the compilation of the tests on Linux
stella.stamenova created this revision.
stella.stamenova added reviewers: labath, zturner, asmith.
Herald added subscribers: lldb-commits, jfb.
Right now only some platforms add pthread to the compilation, however, at least
one of the tests requires the pthread library on Linux as well. Since the
library is available, this change adds it by default on Linux.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54808
Files:
lit/helper/toolchain.py
Index: lit/helper/toolchain.py
===
--- lit/helper/toolchain.py
+++ lit/helper/toolchain.py
@@ -78,7 +78,7 @@
sdk_path = lit.util.to_string(out)
lit_config.note('using SDKROOT: %r' % sdk_path)
flags = ['-isysroot', sdk_path]
-elif platform.system() in ['OpenBSD']:
+elif platform.system() in ['OpenBSD', 'Linux']:
flags = ['-pthread']
Index: lit/helper/toolchain.py
===
--- lit/helper/toolchain.py
+++ lit/helper/toolchain.py
@@ -78,7 +78,7 @@
sdk_path = lit.util.to_string(out)
lit_config.note('using SDKROOT: %r' % sdk_path)
flags = ['-isysroot', sdk_path]
-elif platform.system() in ['OpenBSD']:
+elif platform.system() in ['OpenBSD', 'Linux']:
flags = ['-pthread']
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D54808: [lit] Add pthread to the compilation of the tests on Linux
Lgtm
On Wed, Nov 21, 2018 at 12:10 PM Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> wrote:
> stella.stamenova created this revision.
> stella.stamenova added reviewers: labath, zturner, asmith.
> Herald added subscribers: lldb-commits, jfb.
>
> Right now only some platforms add pthread to the compilation, however, at
> least one of the tests requires the pthread library on Linux as well. Since
> the library is available, this change adds it by default on Linux.
>
>
> Repository:
> rLLDB LLDB
>
> https://reviews.llvm.org/D54808
>
> Files:
> lit/helper/toolchain.py
>
>
> Index: lit/helper/toolchain.py
> ===
> --- lit/helper/toolchain.py
> +++ lit/helper/toolchain.py
> @@ -78,7 +78,7 @@
> sdk_path = lit.util.to_string(out)
> lit_config.note('using SDKROOT: %r' % sdk_path)
> flags = ['-isysroot', sdk_path]
> -elif platform.system() in ['OpenBSD']:
> +elif platform.system() in ['OpenBSD', 'Linux']:
> flags = ['-pthread']
>
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54808: [lit] Add pthread to the compilation of the tests on Linux
zturner added a subscriber: stella.stamenova. zturner added a comment. Lgtm Repository: rLLDB LLDB https://reviews.llvm.org/D54808 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r347412 - [lit] Add pthread to the compilation of the tests on Linux
Author: stella.stamenova
Date: Wed Nov 21 12:16:06 2018
New Revision: 347412
URL: http://llvm.org/viewvc/llvm-project?rev=347412&view=rev
Log:
[lit] Add pthread to the compilation of the tests on Linux
Summary: Right now only some platforms add pthread to the compilation, however,
at least one of the tests requires the pthread library on Linux as well. Since
the library is available, this change adds it by default on Linux.
Reviewers: labath, zturner, asmith
Subscribers: stella.stamenova, jfb, lldb-commits
Differential Revision: https://reviews.llvm.org/D54808
Modified:
lldb/trunk/lit/helper/toolchain.py
Modified: lldb/trunk/lit/helper/toolchain.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/helper/toolchain.py?rev=347412&r1=347411&r2=347412&view=diff
==
--- lldb/trunk/lit/helper/toolchain.py (original)
+++ lldb/trunk/lit/helper/toolchain.py Wed Nov 21 12:16:06 2018
@@ -78,7 +78,7 @@ def use_support_substitutions(config):
sdk_path = lit.util.to_string(out)
lit_config.note('using SDKROOT: %r' % sdk_path)
flags = ['-isysroot', sdk_path]
-elif platform.system() in ['OpenBSD']:
+elif platform.system() in ['OpenBSD', 'Linux']:
flags = ['-pthread']
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54808: [lit] Add pthread to the compilation of the tests on Linux
This revision was not accepted when it landed; it landed in state "Needs
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL347412: [lit] Add pthread to the compilation of the tests on
Linux (authored by stella.stamenova, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D54808?vs=174962&id=174964#toc
Repository:
rL LLVM
https://reviews.llvm.org/D54808
Files:
lldb/trunk/lit/helper/toolchain.py
Index: lldb/trunk/lit/helper/toolchain.py
===
--- lldb/trunk/lit/helper/toolchain.py
+++ lldb/trunk/lit/helper/toolchain.py
@@ -78,7 +78,7 @@
sdk_path = lit.util.to_string(out)
lit_config.note('using SDKROOT: %r' % sdk_path)
flags = ['-isysroot', sdk_path]
-elif platform.system() in ['OpenBSD']:
+elif platform.system() in ['OpenBSD', 'Linux']:
flags = ['-pthread']
Index: lldb/trunk/lit/helper/toolchain.py
===
--- lldb/trunk/lit/helper/toolchain.py
+++ lldb/trunk/lit/helper/toolchain.py
@@ -78,7 +78,7 @@
sdk_path = lit.util.to_string(out)
lit_config.note('using SDKROOT: %r' % sdk_path)
flags = ['-isysroot', sdk_path]
-elif platform.system() in ['OpenBSD']:
+elif platform.system() in ['OpenBSD', 'Linux']:
flags = ['-pthread']
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r347418 - Update call to EvaluateAsInt() to the new syntax.
Author: void
Date: Wed Nov 21 12:44:38 2018
New Revision: 347418
URL: http://llvm.org/viewvc/llvm-project?rev=347418&view=rev
Log:
Update call to EvaluateAsInt() to the new syntax.
Modified:
lldb/trunk/source/Symbol/ClangASTContext.cpp
Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=347418&r1=347417&r2=347418&view=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Wed Nov 21 12:44:38 2018
@@ -5963,10 +5963,10 @@ GetObjCFieldAtIndex(clang::ASTContext *a
if (is_bitfield && ast) {
clang::Expr *bitfield_bit_size_expr = ivar_pos->getBitWidth();
- llvm::APSInt bitfield_apsint;
+ clang::Expr::EvalResult result;
if (bitfield_bit_size_expr &&
- bitfield_bit_size_expr->EvaluateAsInt(bitfield_apsint,
-*ast)) {
+ bitfield_bit_size_expr->EvaluateAsInt(result, *ast)) {
+llvm::APSInt bitfield_apsint = result.Val.getInt();
*bitfield_bit_size_ptr = bitfield_apsint.getLimitedValue();
}
}
@@ -6023,10 +6023,11 @@ CompilerType ClangASTContext::GetFieldAt
if (is_bitfield) {
clang::Expr *bitfield_bit_size_expr = field->getBitWidth();
- llvm::APSInt bitfield_apsint;
+ clang::Expr::EvalResult result;
if (bitfield_bit_size_expr &&
- bitfield_bit_size_expr->EvaluateAsInt(bitfield_apsint,
+ bitfield_bit_size_expr->EvaluateAsInt(result,
*getASTContext())) {
+llvm::APSInt bitfield_apsint = result.Val.getInt();
*bitfield_bit_size_ptr = bitfield_apsint.getLimitedValue();
}
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D54731: [lit] Enable the use of custom user-defined lit commands
labath added a comment. I'd go with the "conservative" approach first. The idea of having lldb loaded inside a lit process does not excite me. One of the problems we have with dotest is that when lldb crashes during the test, it takes a part of the test driver with it which causes some tests to be skipped and the complicates the reporting of the result of the crashed test. It's not as bad right now, as there is still the main process left to report some kind of an error (back in the days when tests were run sequentially in a single process, the entire test suite would just stop), but I still think it would be nice to avoid these issues in the new framework. https://reviews.llvm.org/D54731 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
