Author: jmolenda
Date: Wed Nov 7 10:38:15 2018
New Revision: 346342
URL: http://llvm.org/viewvc/llvm-project?rev=346342&view=rev
Log:
Revert r346285 until I can make it work correctly
the way the bots build lldb.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.
zturner created this revision.
zturner added reviewers: aleksandr.urakov, labath, lemo.
Herald added subscribers: erik.pilkington, JDevlieghere, aprantl.
This is an alternative to https://reviews.llvm.org/D54053 which uses a
different approach. The goal of both is the same - to be able to improv
Author: jmolenda
Date: Wed Nov 7 11:28:03 2018
New Revision: 346347
URL: http://llvm.org/viewvc/llvm-project?rev=346347&view=rev
Log:
Re-commit regularization of the lldb-gtest-build target.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxp
labath added a comment.
Could we reverse the dependencies between the two? I.e., first add the
necessary functionality to lldb-test and then write the test using that? Or
just merge that into a single patch?
Some of the information tested here is already available there (list of
sections) othe
JDevlieghere created this revision.
JDevlieghere added reviewers: jingham, jasonmolenda.
JDevlieghere added a project: LLDB.
Herald added subscribers: teemperor, abidh.
When debugging read-only memory we cannot use software breakpoint. We already
have support for hardware breakpoints and users ca
labath added a comment.
I recall something about linux on arm having a magic unmodifiable (even by
ptrace) page of memory, so this could be useful there too. However, it's not
clear to me how a user is going to figure out that he needs to enable this
setting. Would it make sense to automaticall
krytarowski added a comment.
On NetBSD one has to check PaX MPROTECT property of a traced process.
Something like:
bool IsMPROTECT(pid_t pid) {
#if defined(__NetBSD__)
int mib[3];
int paxflags;
size_t len = sizeof(paxflags);
mib[0] = CTL_PROC;
mib[1] = pid;
mib[2]
JDevlieghere updated this revision to Diff 173015.
JDevlieghere added a comment.
Fix bug for `thread until` and add test case.
https://reviews.llvm.org/D54221
Files:
include/lldb/API/SBBreakpoint.h
include/lldb/Breakpoint/Breakpoint.h
include/lldb/Target/Target.h
include/lldb/Target/Thr
stella.stamenova added a comment.
Some of the file spec changes caused a bunch of failures on Windows. We know
have a silent Buildbot that you can see the failures on as well:
http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/1128/steps/test/logs/stdio
Let me know if you need anyt
stella.stamenova added a comment.
Several of the windows tests that invoke clang-cl have started failing recently
(I am not sure exactly when) and I suspect this change is the culprit. Were you
able to run the tests successfully with this change?
Repository:
rLLDB LLDB
https://reviews.llvm.
JDevlieghere added a comment.
In https://reviews.llvm.org/D54221#1290572, @labath wrote:
> I recall something about linux on arm having a magic unmodifiable (even by
> ptrace) page of memory, so this could be useful there too. However, it's not
> clear to me how a user is going to figure out th
I have not run the dotest suite recently, is that where you’re seeing the
failures? I successfully ran the lit suite and unit tests though
On Wed, Nov 7, 2018 at 1:32 PM Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> wrote:
> stella.stamenova added a comment.
>
> Several of the windo
zturner added a comment.
I have not run the dotest suite recently, is that where you’re seeing the
failures? I successfully ran the lit suite and unit tests though
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54009
___
lldb-commits mailing li
stella.stamenova added a comment.
In https://reviews.llvm.org/D54009#1290644, @zturner wrote:
> I have not run the dotest suite recently, is that where you’re seeing the
> failures? I successfully ran the lit suite and unit tests though
Yes, they are primarily in the lldb-suite but not only:
stella.stamenova added a comment.
TestVla fails on Windows:
http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/1129/steps/test/logs/stdio
AssertionError: False is not True : 'frame var vla' returns expected result,
got '(int []) vla = {}'
I will have time to look in more detail
JDevlieghere updated this revision to Diff 173021.
JDevlieghere added a comment.
Remove `ValidatePlan` implementation for `ThreadPlanPython` as I believe it's
bogus.
https://reviews.llvm.org/D54221
Files:
include/lldb/API/SBBreakpoint.h
include/lldb/Breakpoint/Breakpoint.h
include/lldb/T
aprantl added a comment.
In https://reviews.llvm.org/D53530#1290664, @stella.stamenova wrote:
> TestVla fails on Windows:
> http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/1129/steps/test/logs/stdio
>
> AssertionError: False is not True : 'frame var vla' returns expected
> res
stella.stamenova added a comment.
In https://reviews.llvm.org/D53530#1290680, @aprantl wrote:
> In https://reviews.llvm.org/D53530#1290664, @stella.stamenova wrote:
>
> > TestVla fails on Windows:
> > http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/1129/steps/test/logs/stdio
> >
It’s possible we lost some environment variable propagation, that would do
it. But I’m curious how it was finding the visual studio installation
before my patch.
It also looks like it’s failing finding link.exe (we really should make
lld-link the default). Another fix is to pass -fuse-ld=lld or sp
zturner added a comment.
It’s possible we lost some environment variable propagation, that would do
it. But I’m curious how it was finding the visual studio installation
before my patch.
It also looks like it’s failing finding link.exe (we really should make
lld-link the default). Another fix is
stella.stamenova added a comment.
I haven't verified this yet - but I suspect it is now picking up the clang-cl
that comes with VS rather than the one that was just built.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54009
___
lldb-commits m
Actually maybe it’s the other way around. Are you specifying
LLDB_TEST_COMPILER? If it’s picking up VS’s version, it would definitely be
able to find link.exe
On Wed, Nov 7, 2018 at 2:07 PM Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> wrote:
> stella.stamenova added a comment.
>
>
zturner added a comment.
Actually maybe it’s the other way around. Are you specifying
LLDB_TEST_COMPILER? If it’s picking up VS’s version, it would definitely be
able to find link.exe
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54009
___
lld
shafik added a comment.
@zturner I don't see `AddEnumerationValueToEnumerationType` being called in
`SymbolFile/NativePDB.cpp`
https://github.com/llvm-mirror/lldb/search?q=AddEnumerationValueToEnumerationType&unscoped_q=AddEnumerationValueToEnumerationType
https://reviews.llvm.org/D54003
__
stella.stamenova added a comment.
The builds don't specify the two options for LLDB_TEST_C/CXX_COMPILER, so they
should be picking up the freshly build compilers. We don't have an option for
clang-cl though - so it's never been explicitly specified.
Repository:
rLLDB LLDB
https://reviews.ll
zturner added a subscriber: shafik.
zturner added a comment.
I meant the folder. It’s the first result in your search results. Just
curious, why does your build successfully complete without fixing that
instance?
https://reviews.llvm.org/D54003
___
I meant the folder. It’s the first result in your search results. Just
curious, why does your build successfully complete without fixing that
instance?
On Wed, Nov 7, 2018 at 2:20 PM Shafik Yaghmour via Phabricator <
revi...@reviews.llvm.org> wrote:
> shafik added a comment.
>
> @zturner I don't s
shafik added a comment.
@zturner I was out of date when I posted this diff but I have that file updated
locally and it will show up when I update the diff.
https://reviews.llvm.org/D54003
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
ht
For dotest style tests, the debug format to test is chosen by the test driver.
All the tests should run with any format, but sometimes there are bugs in one
reader or another (or in one version of DWARF or another) so you can skip or
xfail a test based on format. Sounds like this test should b
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
Looking at the extant API's we do seem to prefer "const CompilerType &" over
"const CompilerType" so it seems more consistent to choose that. Other than
that, this looks fine to
Author: jdevlieghere
Date: Wed Nov 7 16:14:50 2018
New Revision: 346375
URL: http://llvm.org/viewvc/llvm-project?rev=346375&view=rev
Log:
[FileSystem] Add convenience method to check for directories.
Replace calls to LLVM's is_directory with calls to LLDB's FileSytem
class. For this I introduced
This revision was automatically updated to reflect the committed changes.
Closed by commit rL346375: [FileSystem] Add convenience method to check for
directories. (authored by JDevlieghere, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.or
shafik updated this revision to Diff 173083.
shafik marked 8 inline comments as done.
shafik added a comment.
Made changes based on comments.
https://reviews.llvm.org/D54003
Files:
include/lldb/Symbol/ClangASTContext.h
packages/Python/lldbsuite/test/expression_command/radar_43822994/Makefil
shafik added inline comments.
Comment at: include/lldb/Symbol/ClangASTContext.h:909
clang::EnumConstantDecl *AddEnumerationValueToEnumerationType(
- lldb::opaque_compiler_type_t type,
- const CompilerType &enumerator_qual_type, const Declaration &decl,
- const c
shafik added a comment.
@jingham @zturner @teemperor @clayborg I believe I have addressed all the
comments.
https://reviews.llvm.org/D54003
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/ll
zturner added inline comments.
Comment at: include/lldb/Symbol/ClangASTContext.h:909
clang::EnumConstantDecl *AddEnumerationValueToEnumerationType(
- lldb::opaque_compiler_type_t type,
- const CompilerType &enumerator_qual_type, const Declaration &decl,
- const
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
This is pretty good, but in all the places where some plan tries to find a
sub-plan to do its job, you are losing the text of the error when that job
fails. So the controlling pla
zturner created this revision.
zturner added a reviewer: clayborg.
Herald added subscribers: JDevlieghere, aprantl.
The first bug is that the implementation of `GetCompilerType` for
`ValueObjectVariable` only requests the forward type. This is insufficient for
printing enum decls. I suspect th
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
Looks good to me.
https://reviews.llvm.org/D54003
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailm
zturner updated this revision to Diff 173095.
zturner added a comment.
I added a test specifically for the bss bug. Even though one of my existing
broken tests became fixed, someone could come down the line and adjust the test
and set one of the variables to 1 which would cause the data to go i
lemo added a comment.
Shouldn't we also handle the general case where raw size < virtual size? (which
would naturally subsume this fix)
Comment at: lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp:1073
+
+ if (section_offset >= section->GetByteSize())
+return 0;
zturner updated this revision to Diff 173103.
zturner added a comment.
I actually found an even better fix for this. LLDB sections already have the
notion of "zero fill sections", we just need to mark the `.data` section as a
zero fill section in this condition. No need to override `ReadSectio
JDevlieghere updated this revision to Diff 173112.
JDevlieghere marked 18 inline comments as done.
JDevlieghere added a comment.
Feedback from Jim
https://reviews.llvm.org/D54221
Files:
include/lldb/API/SBBreakpoint.h
include/lldb/API/SBThreadPlan.h
include/lldb/Breakpoint/Breakpoint.h
43 matches
Mail list logo
