This revision was automatically updated to reflect the committed changes.
Closed by commit rL322803: [CMake] Make check-lldb work with
LLDB_CODESIGN_IDENTITY= (authored by vedantk, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
Author: vedantk
Date: Wed Jan 17 17:16:30 2018
New Revision: 322803
URL: http://llvm.org/viewvc/llvm-project?rev=322803=rev
Log:
[CMake] Make check-lldb work with LLDB_CODESIGN_IDENTITY=''
On Darwin, if a test machine isn't set up for code-signing (see
docs/code-signing.txt), running check-lldb
davide accepted this revision.
davide added a comment.
This revision is now accepted and ready to land.
LGTM with Adrian's suggestion applied, thanks for doing this!
https://reviews.llvm.org/D42215
___
lldb-commits mailing list
vsk updated this revision to Diff 130325.
vsk added a comment.
Thanks for the feedback!
-Print out the path to the debug server as a status message
https://reviews.llvm.org/D42215
Files:
docs/code-signing.txt
test/CMakeLists.txt
Index: test/CMakeLists.txt
jasonmolenda added a comment.
That's a good suggestion. We have some bots using the system debugserver --
and once in a while there's a change to both lldb and debugserver, and the bots
running the older prebuilt debugserver will fail any tests for that patchset.
aprantl added a comment.
How about printing a message (if CMAKE_HOST_APPLE) that the system debugserver
is being used at configure time?
https://reviews.llvm.org/D42215
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
vsk created this revision.
vsk added reviewers: davide, aprantl, jasonmolenda.
Herald added a subscriber: mgorny.
On Darwin, if a test machine isn't set up for code-signing (see
docs/code-signing.txt), running check-lldb should use the system
debugserver instead of the unsigned one built in-tree.
owenpshaw added a comment.
I'm not envisioning that anything else needs to change to use begin/end or care
it's there. I guess the way I look at it, having ObjectFile::LoadInMemory do
begin/end is basically the same as what you're saying about having it be more
process aware.
If Process is
vsk added a comment.
In https://reviews.llvm.org/D42206#979607, @clayborg wrote:
> Are we going to test each unix call that can fail with EINTR? Seems a bit
> overkill.
I think going forward, we should test all functional changes unless it really
is prohibitively expensive to do so. Useful
clayborg added a comment.
Are we going to test each unix call that can fail with EINTR? Seems a bit
overkill.
Repository:
rLLD LLVM Linker
https://reviews.llvm.org/D42206
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
davide requested changes to this revision.
davide added a comment.
This revision now requires changes to proceed.
I took a look and I think this is a sensible change, but we should really test
it.
Repository:
rL LLVM
https://reviews.llvm.org/D42210
vsk added a comment.
In https://reviews.llvm.org/D42206#979570, @jasonmolenda wrote:
> I tried sending signals to lldb-server via kill() and the signal handler
> caught them, the bit of code I had printing out the return value & errno
> value never got executed. The only way I was able to
davide added a comment.
In https://reviews.llvm.org/D42206#979570, @jasonmolenda wrote:
> I tried sending signals to lldb-server via kill() and the signal handler
> caught them, the bit of code I had printing out the return value & errno
> value never got executed. The only way I was able to
jasonmolenda added a comment.
I tried sending signals to lldb-server via kill() and the signal handler caught
them, the bit of code I had printing out the return value & errno value never
got executed. The only way I was able to repo this was by debugging
lldb-server.
Repository:
rLLD
davide added a comment.
In https://reviews.llvm.org/D42206#979566, @vsk wrote:
> Why not take an approach similar to the one in
> https://reviews.llvm.org/D41008? It looks like it's possible to set up a poll
> loop, call signal(), and verify that the loop is still running.
Yes, that was what
vsk requested changes to this revision.
vsk added a comment.
Why not take an approach similar to the one in https://reviews.llvm.org/D41008?
It looks like it's possible to set up a poll loop, call signal(), and verify
that the loop is still running.
Repository:
rLLD LLVM Linker
jasonmolenda created this revision.
jasonmolenda added a reviewer: labath.
jasonmolenda added a project: LLDB.
Herald added a subscriber: llvm-commits.
When lldb-server is in platform mode and waiting for a connection, when it
receives a connection it fork()'s and then runs an
clayborg accepted this revision.
clayborg added a comment.
This is a very common unix thing.
Repository:
rLLD LLVM Linker
https://reviews.llvm.org/D42206
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
jasonmolenda added a comment.
Hmmm, testing this would require launching lldb-server, attaching to it from a
debugger, detaching, and seeing if lldb-server is still running.
Repository:
rLLD LLVM Linker
https://reviews.llvm.org/D42206
___
davide requested changes to this revision.
davide added a comment.
This revision now requires changes to proceed.
I think this one is reasonable, but please wait for another opinion before
committing (and write a test). Pavel touched this code very recently and added
tests for this so it should
jasonmolenda created this revision.
jasonmolenda added a reviewer: davide.
jasonmolenda added a project: LLDB.
Herald added subscribers: llvm-commits, JDevlieghere.
I hit this while trying to debug lldb-server. When lldb-server is waiting for
connections, it will be in
clayborg accepted this revision.
clayborg added inline comments.
This revision is now accepted and ready to land.
Comment at: Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2106
+// a vtable entry) from overloads (which require distinct entries).
+static bool
clayborg added a comment.
My objection to the BeginWriteMemoryBatch and EndWriteMemoryBatch is users must
know to emit these calls when they really just want to call
process.WriteMemory() and not worry about how it is done. Much like writing to
read only code when setting breakpoints, we don't
lhames updated this revision to Diff 130284.
lhames added a comment.
Updated to address review comments:
- assert changed to lldbassert
- comments added
- test case breakpoint comment simplified
- unused import removed from testcase
- testcase Makefile cleaned up
Repository:
rL LLVM
clayborg added a comment.
Looks fine to me. Wait for Pavel to give it the OK since he did more of the
lldb-server testing stuff.
https://reviews.llvm.org/D42195
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
owenpshaw updated this revision to Diff 130258.
owenpshaw added a comment.
- Split testing base into separate review https://reviews.llvm.org/D42195
- Use StreamGDBRemote instead of duplicate new function
- Move qXfer:memory-map xml parsing into GDBRemoteCommunicationClient
- Include
Author: vedantk
Date: Wed Jan 17 12:54:39 2018
New Revision: 322756
URL: http://llvm.org/viewvc/llvm-project?rev=322756=rev
Log:
A third attempt to mark TestRdar12408181.py as skipped
Due to an unfortunate difference between the open source test harness
and our internal harness, applying two
owenpshaw created this revision.
owenpshaw added reviewers: clayborg, labath.
Adds new utilities that make it easier to write test cases for lldb acting as a
client over a gdb-remote connection.
- A GDBRemoteTestBase class that starts a mock GDB server and provides an easy
way to check client
alexandreyy added a comment.
In https://reviews.llvm.org/D41702#978836, @clayborg wrote:
> Looks nice. Only nit is we probably don't need the m_endian member variable.
> See inlined comment.
Thanks. I have changed the code to get the byte order.
https://reviews.llvm.org/D41702
alexandreyy updated this revision to Diff 130236.
alexandreyy added a comment.
Removed m_endian variable.
https://reviews.llvm.org/D41702
Files:
source/Plugins/ABI/SysV-ppc64/ABISysV_ppc64.cpp
source/Plugins/ABI/SysV-ppc64/ABISysV_ppc64.h
Author: vedantk
Date: Wed Jan 17 11:25:12 2018
New Revision: 322740
URL: http://llvm.org/viewvc/llvm-project?rev=322740=rev
Log:
Try again to mark TestRdar12408181.py as skipped
rdar://36417163
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py
clayborg added inline comments.
Comment at: include/lldb/Target/Process.h:1916
+ //--
+ virtual bool BeginWriteMemoryBatch() { return true; }
+
owenpshaw wrote:
> clayborg wrote:
> > labath wrote:
jingham added a comment.
Seems important to me that a name tells what it does without having to know the
implementation details of what it acts on. Particularly for folks new to the
code, having to know one less thing to understand how something that's
important to the logic flow of the
owenpshaw added a comment.
Thanks for the feedback, I'm working on splitting out the testing base into
another patch and making the requested changes. My main unresolved question is
about the write batching, with details below.
Comment at: include/lldb/Target/Process.h:1916
Author: vedantk
Date: Wed Jan 17 10:53:42 2018
New Revision: 322728
URL: http://llvm.org/viewvc/llvm-project?rev=322728=rev
Log:
Skip a flaky test (TestRdar12408181.py)
This test frequently times out on our bots. While we're investigating
the issue, mark the test as skipped so the builds aren't
zturner added a comment.
In a way it's kind of built into the semantics of `llvm::Error` that this is
the only way it could possibly work, since it's a move only type. If you do
this, for example:
Error E = doSomething();
LLDB_LOG_ERROR(E);
you'd get a compilation failure. The only way
jingham added a comment.
This seems fine as a bit of functionality but I'm worried about the name.
There's nothing in "LLDB_LOG_ERROR" that indicates that the error gets cleared,
but that's actually a pretty important piece of its business. Before this
propagates further is there a better
tatyana-krasnukha added a comment.
Herald added a subscriber: llvm-commits.
ping
Greg, Abid, if you disagree with the changes, let me know and I'll close the
revision.
Repository:
rL LLVM
https://reviews.llvm.org/D39969
___
lldb-commits
clayborg added a comment.
Looks nice. Only nit is we probably don't need the m_endian member variable.
See inlined comment.
Comment at: source/Plugins/ABI/SysV-ppc64/ABISysV_ppc64.h:114
+
+ lldb::ByteOrder m_endian;
};
Most other code uses "m_byte_order" as
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Very nice overall. See inlined comments. Big issues are:
- GDBRemoteCommunication::WriteEscapedBinary() is not needed as
StreamGDBRemote::PutEscapedBytes() does this already
-
Looks fine to me too
On Wed, Jan 17, 2018 at 8:56 AM Davide Italiano via Phabricator <
revi...@reviews.llvm.org> wrote:
> davide added a comment.
>
> I think this is fine, but I'll defer to Zachary.
>
>
> https://reviews.llvm.org/D42182
>
>
>
>
___
davide added a comment.
I think this is fine, but I'll defer to Zachary.
https://reviews.llvm.org/D42182
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
alexandreyy updated this revision to Diff 130180.
alexandreyy added a comment.
Herald added a subscriber: JDevlieghere.
Merged ppc64le and ppc64 plugins.
https://reviews.llvm.org/D41702
Files:
source/Plugins/ABI/SysV-ppc64/ABISysV_ppc64.cpp
source/Plugins/ABI/SysV-ppc64/ABISysV_ppc64.h
This revision was automatically updated to reflect the committed changes.
Closed by commit rL322666: [lldb][PPC64] Fixed long double variables dump
(authored by labath, committed by ).
Repository:
rL LLVM
https://reviews.llvm.org/D42083
Files:
lldb/trunk/source/Core/DumpDataExtractor.cpp
Author: labath
Date: Wed Jan 17 07:11:20 2018
New Revision: 322666
URL: http://llvm.org/viewvc/llvm-project?rev=322666=rev
Log:
[lldb][PPC64] Fixed long double variables dump
Summary:
LLDB's DumpDataExtractor was not prepared to handle PowerPC's long double type:
PPCDoubleDouble.
As it is
labath created this revision.
labath added reviewers: davide, zturner, jingham, clayborg.
Herald added a subscriber: emaste.
The difference between this and regular LLDB_LOG is that this one clears
the error object unconditionally. This was inspired by the
ObjectFileELF bug (r322664), where the
Author: labath
Date: Wed Jan 17 06:40:25 2018
New Revision: 322664
URL: http://llvm.org/viewvc/llvm-project?rev=322664=rev
Log:
Fix assertion in ObjectFileELF
In D40616 I (mistakenly) assumed that logging an llvm::Error would clear
it. This of course is only true if logging is actually enabled.
Author: labath
Date: Wed Jan 17 05:46:06 2018
New Revision: 322653
URL: http://llvm.org/viewvc/llvm-project?rev=322653=rev
Log:
Simplify some LogTest tests
This removes boilerplate for setting up a log channel and capturing the
output from some of the tests. I do this by moving the setup code
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Awesome, thanks.
https://reviews.llvm.org/D42083
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
labath added a comment.
First, I'd like to thank you for taking the time to create a method for testing
patches like these. I think this will be very valuable for all out-of-tree stub
support patches we will get in the future. Could I ask that you split out the
generic test-suite-stuff part of
50 matches
Mail list logo
