labath added a comment.
Comment at: include/lldb/Interpreter/Args.h:196-197
+ llvm::ArrayRef GetArgumentArrayRef() const {
+return {static_cast(m_argv.data()),
+m_argv.size() - 1};
+ }
zturner wrote:
> can this be written `return makeArrayRef
labath updated this revision to Diff 89996.
labath marked 3 inline comments as done.
labath added a comment.
Address review comments
https://reviews.llvm.org/D30402
Files:
include/lldb/Core/Debugger.h
include/lldb/Core/Log.h
include/lldb/Interpreter/Args.h
source/API/SBDebugger.cpp
so
It looks like that in this case (and possibly many others) a wrapper
class is not necessary. If we just want to log the inputs and outputs
of mmap(), we just need to wrap the factory function (as we have done
here) and let the users access the llvm class directly.
On 27 February 2017 at 20:05, Jim
labath updated this revision to Diff 9.
labath added a comment.
rebase on top of tree
https://reviews.llvm.org/D30402
Files:
include/lldb/Core/Debugger.h
include/lldb/Core/Log.h
include/lldb/Interpreter/Args.h
source/API/SBDebugger.cpp
source/Commands/CommandObjectLog.cpp
source
labath created this revision.
Herald added a subscriber: mgorny.
The test runner has code to autodetect this, but it's not very smart --
in particular, it fails in the case where we build the test executables
with the just-built clang. Since cmake already has the knowledge about
the right toolchai
nitesh.jain created this revision.
The MatchesModuleSpec() should return false if module_ref is not found.
https://reviews.llvm.org/D30454
Files:
source/Core/Module.cpp
Index: source/Core/Module.cpp
===
--- source/Core/Module.c
Author: labath
Date: Tue Feb 28 06:32:45 2017
New Revision: 296470
URL: http://llvm.org/viewvc/llvm-project?rev=296470&view=rev
Log:
Switch SBWatchpoint to use a weak_ptr to the underlying object
Modified:
lldb/trunk/include/lldb/API/SBWatchpoint.h
lldb/trunk/packages/Python/lldbsuite/te
nitesh.jain created this revision.
This patch add support for core file. This patch includes
- Separation of register context which was earlier share between Linux and
FreeBSD.
- Add support to analyse Linux core file for all three ABI (N32, N64 and O32)
https://reviews.llvm.org/D30457
F
labath created this revision.
Herald added subscribers: srhines, danalbert, emaste.
On older android targets, we needed a dlopen rename workaround to get
"process load" working. Since API 25 this is not required as the targets
have a proper libdl so with the function names one would expect.
To ma
tberghammer accepted this revision.
tberghammer added a comment.
This revision is now accepted and ready to land.
LGTM, assuming that it works on all 3 OSes
Comment at: packages/Python/lldbsuite/test/make/Android.rules:1
+NDK_ROOT := $(shell dirname $(CC))/../../../../..
+NDK_R
labath abandoned this revision.
labath added a comment.
The sdk version I used here is incorrect. Shelve this until we can get the
right version here.
https://reviews.llvm.org/D30460
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://
labath added a comment.
Have you tried running the
`test/testcases/functionalities/postmortem/elf-core/make-core.sh` script? Does
it generate a reasonably-sized core file (potentially you may need to increase
the stack limit slightly). It would be great to have a mips core file test for
this.
labath added a comment.
I am not sure this is correct... looking at the other checks in this function,
they seem to be following the same pattern... could you explain where you ran
into this?
https://reviews.llvm.org/D30454
___
lldb-commits mailin
labath added a comment.
Comment at: packages/Python/lldbsuite/test/make/Android.rules:1
+NDK_ROOT := $(shell dirname $(CC))/../../../../..
+NDK_ROOT := $(realpath $(NDK_ROOT))
tberghammer wrote:
> Will this file work on Windows (e.g. dirname, realpath, forward
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
This logic is wrong. If there is no object name, true should be returned. The
old logic is correct.
https://reviews.llvm.org/D30454
__
clayborg added a comment.
Object name is used for a module spec where the file is "/tmp/foo.a" and the
object name is "bar.o". So this is for named objects within a container file
like a BSD archive. If there is no object name, it doesn't need to be matched.
If there is an object name, then the
Lgtm
On Tue, Feb 28, 2017 at 3:08 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath updated this revision to Diff 9.
> labath added a comment.
>
> rebase on top of tree
>
>
> https://reviews.llvm.org/D30402
>
> Files:
> include/lldb/Core/Debugger.h
> include/lldb/
clayborg resigned from this revision.
clayborg added a comment.
I will let Pavel do this review as it is in his area of expertise.
https://reviews.llvm.org/D30457
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bi
Author: zturner
Date: Tue Feb 28 11:59:59 2017
New Revision: 296495
URL: http://llvm.org/viewvc/llvm-project?rev=296495&view=rev
Log:
Fix incorrect logic in StackFrame::Disassemble.
This had broken as the result of some previous cleanup.
Modified:
lldb/trunk/source/Target/StackFrame.cpp
Mod
No test case?
Jim
> On Feb 28, 2017, at 9:59 AM, Zachary Turner via lldb-commits
> wrote:
>
> Author: zturner
> Date: Tue Feb 28 11:59:59 2017
> New Revision: 296495
>
> URL: http://llvm.org/viewvc/llvm-project?rev=296495&view=rev
> Log:
> Fix incorrect logic in StackFrame::Disassemble.
>
>
I'm not even sure how to exercise this code path. Granted, the reason it
broke at all is because of no test case, but I feel like someone who
understands this code should probably prepare a test case for it. (I know
in the past Jason has said that it was notoriously hard to write test cases
for d
SBStackFrame::Disassemble calls StackFrame::Disassemble to do its job. From
the looks of it, your goof would cause lldb never to return any instructions
when asked to disassemble a stack frame, since StackFrame does the work lazily
and the error was to NOT do the work when the disassembly is em
Make that SBFrame::Disassemble...
Jim
> On Feb 28, 2017, at 10:21 AM, Jim Ingham wrote:
>
> SBStackFrame::Disassemble calls StackFrame::Disassemble to do its job. From
> the looks of it, your goof would cause lldb never to return any instructions
> when asked to disassemble a stack frame, si
Author: jingham
Date: Tue Feb 28 12:57:54 2017
New Revision: 296504
URL: http://llvm.org/viewvc/llvm-project?rev=296504&view=rev
Log:
Fix a bug in r294611 w.r.t. Darwin Kernel debugging.
Modified:
lldb/trunk/include/lldb/Target/DynamicLoader.h
lldb/trunk/include/lldb/Target/Process.h
eugene added inline comments.
Comment at: source/Plugins/Process/Utility/RegisterContextFreeBSD_mips64.cpp:31
+// Number of register sets provided by this context.
+enum { k_num_register_sets = 1 };
+
Here and below why not use
constexpr size_t k_num_register_s
Author: zturner
Date: Tue Feb 28 14:29:20 2017
New Revision: 296516
URL: http://llvm.org/viewvc/llvm-project?rev=296516&view=rev
Log:
Wrap the call to UndecorateSymbolName in a mutex.
MSDN documents that this function is not thread-safe, so we
wrap it in a global mutex.
Modified:
lldb/trunk/
Author: zturner
Date: Tue Feb 28 14:30:31 2017
New Revision: 296517
URL: http://llvm.org/viewvc/llvm-project?rev=296517&view=rev
Log:
clang-format the Mangled changes.
Modified:
lldb/trunk/source/Core/Mangled.cpp
Modified: lldb/trunk/source/Core/Mangled.cpp
URL:
http://llvm.org/viewvc/llvm-
Author: jmolenda
Date: Tue Feb 28 16:31:18 2017
New Revision: 296531
URL: http://llvm.org/viewvc/llvm-project?rev=296531&view=rev
Log:
Add additional areas I'm responsible for in the lldb codebase.
Modified:
lldb/trunk/CODE_OWNERS.txt
Modified: lldb/trunk/CODE_OWNERS.txt
URL:
http://llvm.or
Writing SB API tests for the disassembler is easy, as Jim notes there is an
SBFrame::Disassemble() method that maps directly on to this call.
I've written unit tests that create a disassembler -- I do it for the unwind
tests. It's easy when you have an array of bytes to feed directly into the
On Tue, Feb 28, 2017 at 3:07 PM Jason Molenda wrote:
> At it's core, lldb is a real world tool that thousands of people depend
> on; breaking it or introducing bugs for little gain beyond aesthetics is a
> very poor tradeoff.
>
Just for the record, I disagree with this assertion that there is li
> On Feb 28, 2017, at 3:14 PM, Zachary Turner wrote:
>
> On Tue, Feb 28, 2017 at 3:07 PM Jason Molenda wrote:
> At it's core, lldb is a real world tool that thousands of people depend on;
> breaking it or introducing bugs for little gain beyond aesthetics is a very
> poor tradeoff.
>
> Ju
Another principle that seems useful here is not to make this sort of logic
change unless this is code you are currently working on. When you have the
actual purpose of the code in your head, it is fairly easy to make this sort of
change correctly. You know what the code is supposed to be doing
That patch was not really about early returns, it was about using
StringRef. So my comment about the aesthetics was referring to the patch
in general. The early return was more of a drive by, since I was already
touching the code. In that respect I was just following the well
documented and wide
> On Feb 28, 2017, at 3:36 PM, Zachary Turner wrote:
>
> That patch was not really about early returns, it was about using StringRef.
> So my comment about the aesthetics was referring to the patch in general.
> The early return was more of a drive by, since I was already touching the
> cod
It makes me uncomfortable to have these whole-project-ranging change sets going
into the source, one example being const char * -> StringRef) for such small
benefit. Yes there were a few methods where we were doing string parsing and
tokenizing which became much smaller and easier to understand
Author: jmolenda
Date: Tue Feb 28 18:00:45 2017
New Revision: 296548
URL: http://llvm.org/viewvc/llvm-project?rev=296548&view=rev
Log:
Greg Clayton is no longer working at Apple, he will continue to
review patches etc from his clayborg email address.
Modified:
lldb/trunk/CODE_OWNERS.txt
Modi
On Tue, Feb 28, 2017 at 3:49 PM Jim Ingham wrote:
>
> > On Feb 28, 2017, at 3:36 PM, Zachary Turner wrote:
> >
> > That patch was not really about early returns, it was about using
> StringRef. So my comment about the aesthetics was referring to the patch
> in general. The early return was mor
On Tue, Feb 28, 2017 at 4:09 PM Jason Molenda wrote:
>
> You mentioned that this kind of mechanical churn of the code is something
> everyone else in the LLVM/LLDB community supports. I don't know about the
> LLVM community, but I strongly argue that this is the wrong way to develop
> a stable,
> On Feb 28, 2017, at 4:15 PM, Zachary Turner wrote:
>
>
>
> On Tue, Feb 28, 2017 at 3:49 PM Jim Ingham wrote:
>
> > On Feb 28, 2017, at 3:36 PM, Zachary Turner wrote:
> >
> > That patch was not really about early returns, it was about using
> > StringRef. So my comment about the aestheti
39 matches
Mail list logo
