I was thinking of a simple test like "call get on an existing file and
make sure it returns something reasonable" and "call get on a
non-existing file and make sure it returns null". This is a very thin
wrapper over over the llvm code, so I don't insist on it though...
On 24 February 2017 at 15:18
labath added a comment.
I like `bkpt_sp`. I will rename it before submission. It does not make the diff
any larger as I have had to rename all occurrences of it anyway.
https://reviews.llvm.org/D30249
___
lldb-commits mailing list
lldb-commits@list
Author: labath
Date: Mon Feb 27 05:05:34 2017
New Revision: 296328
URL: http://llvm.org/viewvc/llvm-project?rev=296328&view=rev
Log:
Switch SBBreakpoint to storing a weak_ptr of the internal breakpoint object
Summary:
There is nothing we can do with the breakpoint once the associated
target becom
Author: labath
Date: Mon Feb 27 05:05:39 2017
New Revision: 296329
URL: http://llvm.org/viewvc/llvm-project?rev=296329&view=rev
Log:
Log: Fix a regression in handling log options
The channel refactor introduced a regression where we were not honoring
the log options passed when enabling the chann
This revision was automatically updated to reflect the committed changes.
Closed by commit rL296328: Switch SBBreakpoint to storing a weak_ptr of the
internal breakpoint object (authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D30249?vs=89645&id=89858#toc
Repository:
rL
Author: labath
Date: Mon Feb 27 06:21:20 2017
New Revision: 296334
URL: http://llvm.org/viewvc/llvm-project?rev=296334&view=rev
Log:
Fix MinidumpParserTest on 32-bit arches
load_size should be 64-bit unconditionally to match the underlying API.
This makes sure the MAX value correctly signals to a
Author: labath
Date: Mon Feb 27 06:21:16 2017
New Revision: 296333
URL: http://llvm.org/viewvc/llvm-project?rev=296333&view=rev
Log:
Remove the callback-based log channel registration mechanism
All the existing channels have beens switched to the new mechanism and
this code is now unused.
Modifi
labath created this revision.
Use StringRef and ArrayRef where possible. This adds an accessor to the
Args class to get a view of the arguments as ArrayRef.
https://reviews.llvm.org/D30402
Files:
include/lldb/Core/Debugger.h
include/lldb/Core/Log.h
include/lldb/Interpreter/Args.h
source
This revision was automatically updated to reflect the committed changes.
Closed by commit rL296335: Merge Linux and FreeBSD arm register contexts
(authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D27126?vs=79287&id=89866#toc
Repository:
rL LLVM
https://reviews.llvm.or
Author: labath
Date: Mon Feb 27 07:00:50 2017
New Revision: 296335
URL: http://llvm.org/viewvc/llvm-project?rev=296335&view=rev
Log:
Merge Linux and FreeBSD arm register contexts
Summary:
These two register contexts were identical, so this shouldn't cause any
regressions, but I'd appreciate it if
labath created this revision.
Herald added a subscriber: srhines.
This teaches the test makefiles about the Android NDK, so we are able to
run the tests without first going through the make_standalone_toolchain
script. The motivation for this is the ability to run both libc++ and
libstdc++ tests t
Author: kamil
Date: Mon Feb 27 11:52:48 2017
New Revision: 296360
URL: http://llvm.org/viewvc/llvm-project?rev=296360&view=rev
Log:
Support NetBSD Thread ID in lldb-server tests
Summary:
Native Thread ID is retrieved with _lwp_self() on NetBSD.
The returned value is of type int32_t, but for cons
This is kind of after the fact, but why didn't we reuse DataBufferMemoryMap for
the Memory Map data buffer that now happens to be backed by an LLVM
implementation? DataBufferLLVM doesn't really tell anybody what the thing does
w/o looking up the implementation.
Jim
> On Feb 27, 2017, at 2:56
I didn't refer to mmaping in the name because LLVM's MemoryBuffer is not
necessarily mmap'ed. It might be mmap'ed and it might not be. Depends on
various factors such as whether you specify the IsVolatile flag, how big
the file is, and maybe a few other things.
After this change we have DataBuff
I worry about stripping out the wrappers, because there are some differences in
how lldb operates from llvm that I don't think we want to push down into llvm -
in this case I'm thinking particularly about logging. DataBufferMemoryMap did
a bunch of logging, which presumably would get lost if yo
There may be some cases where we're no longer mmaping where we used to, but
looking at LLVM's implementation, that would only happen if the file is
fairly small, and there's a comment in LLVM explaining why they don't mmap
small files. So I think that's actually an improvement for LLDB (although
I
> On Feb 27, 2017, at 11:49 AM, Zachary Turner wrote:
>
> There may be some cases where we're no longer mmaping where we used to, but
> looking at LLVM's implementation, that would only happen if the file is
> fairly small, and there's a comment in LLVM explaining why they don't mmap
> small
Oh that wasn't in response to the comment about wrapper classes, that was
just a general comment about the fact that we lose logging by moving to
LLVM's implementation at all. If we have our own implementation, we could
in theory log at various stages of the mmaping process, but by moving to a
lib
zturner added inline comments.
Comment at: include/lldb/Interpreter/Args.h:196-197
+ llvm::ArrayRef GetArgumentArrayRef() const {
+return {static_cast(m_argv.data()),
+m_argv.size() - 1};
+ }
can this be written `return makeArrayRef(m_argv).drop
Having library functions that don't return good errors seems like such an
obvious failing that it shouldn't be hard to motivate fixing that. Then our
logging can go in the wrapper classes, using those errors. That seems like a
pattern that solves the "don't duplicate code" problem and the "lld
Author: penryu
Date: Mon Feb 27 16:56:27 2017
New Revision: 296406
URL: http://llvm.org/viewvc/llvm-project?rev=296406&view=rev
Log:
update pbxproj to match cmake config, broken in r296335
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
Author: jmolenda
Date: Mon Feb 27 17:31:29 2017
New Revision: 296412
URL: http://llvm.org/viewvc/llvm-project?rev=296412&view=rev
Log:
Ah, this was an early exit to leave built products around, it wasn't meant to
be checked in.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/api/multiple
Author: eugene
Date: Mon Feb 27 20:40:34 2017
New Revision: 296427
URL: http://llvm.org/viewvc/llvm-project?rev=296427&view=rev
Log:
Add a comment to describe purpose of signal-filtering test
Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote
23 matches
Mail list logo
