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
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
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
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
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
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
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
zturner added inline comments.
Comment at: include/lldb/Symbol/ClangASTContext.h:909
clang::EnumConstantDecl *AddEnumerationValueToEnumerationType(
- lldb::opaque_compiler_type_t type,
- const CompilerType _qual_type, const Declaration ,
- const char *name,
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
shafik added inline comments.
Comment at: include/lldb/Symbol/ClangASTContext.h:909
clang::EnumConstantDecl *AddEnumerationValueToEnumerationType(
- lldb::opaque_compiler_type_t type,
- const CompilerType _qual_type, const Declaration ,
- const char *name,
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
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:
Author: jdevlieghere
Date: Wed Nov 7 16:14:50 2018
New Revision: 346375
URL: http://llvm.org/viewvc/llvm-project?rev=346375=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 a
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
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
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
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
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
___
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
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_q=AddEnumerationValueToEnumerationType
https://reviews.llvm.org/D54003
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
___
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.
>
>
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
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
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
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
> >
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
>
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
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
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:
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
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
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
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
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
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]
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
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
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)
Author: jmolenda
Date: Wed Nov 7 11:28:03 2018
New Revision: 346347
URL: http://llvm.org/viewvc/llvm-project?rev=346347=rev
Log:
Re-commit regularization of the lldb-gtest-build target.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
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
Author: jmolenda
Date: Wed Nov 7 10:38:15 2018
New Revision: 346342
URL: http://llvm.org/viewvc/llvm-project?rev=346342=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:
42 matches
Mail list logo
