[lldb-dev] Build failure with llvm/IR/Attributes.gen?
Hi everyone, Starting a few days ago (between Sept 22nd and 23rd) my nightly builds including lldb starting failing: In file included from /path/to/llvm/include/llvm/IR/Argument.h:19:0, from /path/to/llvm/include/llvm/IR/Function.h:22, from /path/to/llvm/include/llvm/IR/Module.h:21, from /path/to/llvm/tools/lldb/include/lldb/Expression/IRExecutionUnit.h:22, from /path/to/llvm/tools/lldb/source/Expression/ExpressionVariable.cpp:12: /path/to/llvm/include/llvm/IR/Attributes.h:71:38: fatal error: llvm/IR/Attributes.gen: No such file or directory #include "llvm/IR/Attributes.gen" ^ compilation terminated. This might be simply the result of some unexpressed dependency in the cmake files (my build uses make -j72, so it tends to find these kinds of issues when they come up). Any ideas? Thanks again, Hal -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 29129] lldb-mi expressions that have spaces aren't parsed properly for -var-create
https://llvm.org/bugs/show_bug.cgi?id=29129 edmu...@microsoft.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from edmu...@microsoft.com --- This was fixed and merged. https://reviews.llvm.org/D24202 -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Build failure with llvm/IR/Attributes.gen?
- Original Message - > From: "Hal Finkel via lldb-dev" > To: lldb-dev@lists.llvm.org > Sent: Thursday, September 29, 2016 2:51:03 PM > Subject: [lldb-dev] Build failure with llvm/IR/Attributes.gen? > > Hi everyone, > > Starting a few days ago (between Sept 22nd and 23rd) my nightly > builds including lldb starting failing: > > In file included from /path/to/llvm/include/llvm/IR/Argument.h:19:0, > from /path/to/llvm/include/llvm/IR/Function.h:22, > from /path/to/llvm/include/llvm/IR/Module.h:21, > from > > /path/to/llvm/tools/lldb/include/lldb/Expression/IRExecutionUnit.h:22, > from > > /path/to/llvm/tools/lldb/source/Expression/ExpressionVariable.cpp:12: > /path/to/llvm/include/llvm/IR/Attributes.h:71:38: fatal error: > llvm/IR/Attributes.gen: No such file or directory > #include "llvm/IR/Attributes.gen" > ^ > compilation terminated. > > This might be simply the result of some unexpressed dependency in the > cmake files (my build uses make -j72, so it tends to find these > kinds of issues when they come up). Any ideas? [+Chris B.] Doing this seems to help: diff --git a/CMakeLists.txt b/CMakeLists.txt index 85d4b51..9615a3c 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -765,9 +765,9 @@ add_subdirectory(utils/TableGen) # an entire module might include header, which depends on intrinsics_gen. This # should be right after LLVMSupport and LLVMTableGen otherwise we introduce a # circular dependence. -if (LLVM_ENABLE_MODULES) +#if (LLVM_ENABLE_MODULES) list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen) -endif(LLVM_ENABLE_MODULES) +#endif(LLVM_ENABLE_MODULES) add_subdirectory(include/llvm) but that does not seem like a real solution. -Hal > > Thanks again, > Hal > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 30568] New: [lldb-mi] -var-assign doesn't accept some valid values
https://llvm.org/bugs/show_bug.cgi?id=30568 Bug ID: 30568 Summary: [lldb-mi] -var-assign doesn't accept some valid values Product: lldb Version: 3.9 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: edmu...@microsoft.com CC: llvm-b...@lists.llvm.org Classification: Unclassified Related to https://llvm.org/bugs/show_bug.cgi?id=30423 -var-assign should allow assigning certain values to variables. The supported types seems to be ints and floats (different encodings). For example, assigning a valid value such as "true", "false", "'a'" all fail. These assignments succeed if the "equivalent" integer value is used instead (1, 0, 97 (ascii), respectively). Other debuggers like GDB do support these values to be used with the command -var-assign. Repro (where z is a boolean variable): -var-create - - "z" --thread 1 --frame 0 ^done,name="var2",numchild="0",value="true",type="bool",thread-id="1",has_more="0" (gdb) ## Assigning "false" fails -var-assign var2 "false" ^error,msg="expression could not be evaluated" (gdb) ## Assigning "0" succeeds -var-assign var2 "0" ^done,value="false" (gdb) -var-evaluate-expression var2 ^done,value="false" (gdb) The expected behavior is the same as GDB: -var-create - * "z" ^done,name="var1",numchild="0",value="true",type="bool",thread-id="1",has_more="0" (gdb) -var-assign var1 "false" ^done,value="false" (gdb) -var-evaluate-expression var1 ^done,value="false" (gdb) -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Build failure with llvm/IR/Attributes.gen?
Hal, thanks for the heads up. I just committed a patch that should resolve this in r282803. Thanks! -Chris > On Sep 29, 2016, at 1:49 PM, Hal Finkel wrote: > > - Original Message - >> From: "Hal Finkel via lldb-dev" >> To: lldb-dev@lists.llvm.org >> Sent: Thursday, September 29, 2016 2:51:03 PM >> Subject: [lldb-dev] Build failure with llvm/IR/Attributes.gen? >> >> Hi everyone, >> >> Starting a few days ago (between Sept 22nd and 23rd) my nightly >> builds including lldb starting failing: >> >> In file included from /path/to/llvm/include/llvm/IR/Argument.h:19:0, >> from /path/to/llvm/include/llvm/IR/Function.h:22, >> from /path/to/llvm/include/llvm/IR/Module.h:21, >> from >> >> /path/to/llvm/tools/lldb/include/lldb/Expression/IRExecutionUnit.h:22, >> from >> >> /path/to/llvm/tools/lldb/source/Expression/ExpressionVariable.cpp:12: >> /path/to/llvm/include/llvm/IR/Attributes.h:71:38: fatal error: >> llvm/IR/Attributes.gen: No such file or directory >> #include "llvm/IR/Attributes.gen" >> ^ >> compilation terminated. >> >> This might be simply the result of some unexpressed dependency in the >> cmake files (my build uses make -j72, so it tends to find these >> kinds of issues when they come up). Any ideas? > > [+Chris B.] > > Doing this seems to help: > > diff --git a/CMakeLists.txt b/CMakeLists.txt > index 85d4b51..9615a3c 100644 > --- a/CMakeLists.txt > +++ b/CMakeLists.txt > @@ -765,9 +765,9 @@ add_subdirectory(utils/TableGen) > # an entire module might include header, which depends on intrinsics_gen. This > # should be right after LLVMSupport and LLVMTableGen otherwise we introduce a > # circular dependence. > -if (LLVM_ENABLE_MODULES) > +#if (LLVM_ENABLE_MODULES) > list(APPEND LLVM_COMMON_DEPENDS intrinsics_gen) > -endif(LLVM_ENABLE_MODULES) > +#endif(LLVM_ENABLE_MODULES) > > add_subdirectory(include/llvm) > > but that does not seem like a real solution. > > -Hal > >> >> Thanks again, >> Hal >> >> -- >> Hal Finkel >> Lead, Compiler Technology and Programming Languages >> Leadership Computing Facility >> Argonne National Laboratory >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] RFC: Break/Watchpoint Callback storage and validation
As per discussion in another thread
(http://lists.llvm.org/pipermail/lldb-dev/2016-September/011397.html)
I have started refactoring the private side of Break/Watchpoint.
Mostly this involves fairly trivial and obvious changes and I expect the
first patch to be ready fairly soon.
Still, there are a couple points I would like to get feedback on.
1. Having reviewed the llvm::function_ref template (see
http://llvm.org/docs/doxygen/html/STLExtras_8h_source.html#l00059), I
can tentatively agree that it is suitable for break/watch callbacks.
The concern is the "This class does not own the callable, so it is not
in general safe to store a function_ref" bit. This is not an issue
provided I ensure that
a) StoppointOptions does "own" the callable OR ensures its validity
prior to invoking the callback
AND
b) ~StoppointOptions behaves responsibly in the face of this provision
If we are just handed a function pointer then there is nothing to clean up.
If we are handed a callable object things are a little more complex.
We could make a copy of the provided object and just let the dtors clean
up for us. That does put a few restrictions on the type of callback
objects we can accept (e.g. user must account for side effects in
ctor/dtors, object must be copy constructible, performance and memory
overhead).
We could require move semantics.
We could use unique_ptr, shared_ptr, weak_ptr.
Feelings?
2. llvm::function_ref and std::function are great, but they accept ANY
callable.
When I write templates I generally write helper classes which try to
validate the template params.
Here is a simple sketch of the type of thing I mean:
```cpp
#include
namespace callback {
template
struct IsReturnTypeValid {
static constexpr bool value = false;
};
template
struct IsReturnTypeValid {
static constexpr bool value = std::is_same<
typename std::remove_const::type,
bool
>::value;
};
template
constexpr
void assert_valid_callback() {
static_assert(IsReturnTypeValid::value,
"Return type of Stoppoint callback must be bool!");
}
} // end namespace ::callback
bool valid(void* userData, int some, double other, char params) {
return true;
}
double invalid(int stuff, double moreStuff) {
return 0;
}
int main(void) {
// compiles
callback::assert_valid_callback();
// will not compile
callback::assert_valid_callback();
return 0;
}
```
I find that the makes debugging far easier for people using the library.
I also find that writing this kind of SFINAE stuff can be difficult and
time consuming.
Do you think this sort of validation is actually an asset (especially
since it will only be available on the private side of things in the
near term)?
signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
