Author: eugene
Date: Mon Feb 27 20:40:34 2017
New Revision: 296427
URL: http://llvm.org/viewvc/llvm-project?rev=296427=rev
Log:
Add a comment to describe purpose of signal-filtering test
Modified:
Author: jmolenda
Date: Mon Feb 27 17:31:29 2017
New Revision: 296412
URL: http://llvm.org/viewvc/llvm-project?rev=296412=rev
Log:
Ah, this was an early exit to leave built products around, it wasn't meant to
be checked in.
Modified:
Author: penryu
Date: Mon Feb 27 16:56:27 2017
New Revision: 296406
URL: http://llvm.org/viewvc/llvm-project?rev=296406=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
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
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
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
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
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
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
Author: kamil
Date: Mon Feb 27 11:52:48 2017
New Revision: 296360
URL: http://llvm.org/viewvc/llvm-project?rev=296360=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
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
Author: labath
Date: Mon Feb 27 07:00:50 2017
New Revision: 296335
URL: http://llvm.org/viewvc/llvm-project?rev=296335=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 you
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=89866#toc
Repository:
rL LLVM
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
Author: labath
Date: Mon Feb 27 06:21:16 2017
New Revision: 296333
URL: http://llvm.org/viewvc/llvm-project?rev=296333=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.
Modified:
Author: labath
Date: Mon Feb 27 06:21:20 2017
New Revision: 296334
URL: http://llvm.org/viewvc/llvm-project?rev=296334=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
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=89858#toc
Repository:
rL
Author: labath
Date: Mon Feb 27 05:05:39 2017
New Revision: 296329
URL: http://llvm.org/viewvc/llvm-project?rev=296329=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 channel.
Author: labath
Date: Mon Feb 27 05:05:34 2017
New Revision: 296328
URL: http://llvm.org/viewvc/llvm-project?rev=296328=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 becomes
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
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
21 matches
Mail list logo
