hintonda added a comment.
Actually, it wouldn't matter for this one due to alignment.
https://reviews.llvm.org/D39436
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
hintonda added a comment.
In https://reviews.llvm.org/D39436#911875, @clayborg wrote:
> A few general things: don't modify FileSpec, we have many of these objects
> and we can't increase their size without directly affecting memory usage.
> FileSpec objects represent one file on disk, not mul
Author: jmolenda
Date: Tue Oct 31 18:38:42 2017
New Revision: 317067
URL: http://llvm.org/viewvc/llvm-project?rev=317067&view=rev
Log:
Remove Sean Callanan from the CODE_OWNERS, he won't have time
to participate in lldb going forward. Jim Ingham is adopting
the areas he was responsible for.
Modi
Author: jingham
Date: Tue Oct 31 15:38:24 2017
New Revision: 317043
URL: http://llvm.org/viewvc/llvm-project?rev=317043&view=rev
Log:
Modernize the example cmdtemplate.py.
This version relies on a newer and more convenient way
to use a class to implement a command. It has been in place
since ear
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
This looks good.
https://reviews.llvm.org/D35666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailma
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
It seems awkward to me to be returning empty ValueObjectSP's by returning
nullptr and then relying on conversion. We don't do it that way in most of the
other formatters. If ther
On Tue, Oct 31, 2017 at 10:43 AM Jim Ingham wrote:
>
>
> > On Oct 31, 2017, at 9:05 AM, Zachary Turner wrote:
> >
> > This is a case where I think a new API *would* be warranted. But it
> would not be an API specifically for the -m option. It would instead be an
> API that introduces an `SBBre
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
Sure, this seems fine to me. Not sure why this was introduced, the svn history
has become hard to follow. But this seems overly specific for an integer
assignment operator.
https://revi
Not directly, though you can get the ID from the breakpoint you've made, and
then do:
debugger.HandleCommand("breakpoint modify -m 0 %d"%(ID))
Jim
> On Oct 31, 2017, at 8:32 AM, Don Hinton wrote:
>
> Btw, is there a way to pass the '-m' option via the SB API? I'd like to
> exclude matches
> On Oct 31, 2017, at 9:05 AM, Zachary Turner wrote:
>
> This is a case where I think a new API *would* be warranted. But it would
> not be an API specifically for the -m option. It would instead be an API
> that introduces an `SBBreakpointOptions` class, and then add a method called
> `Br
Agreed, get ASAN working and we will find this issue and any remaining issues.
> On Oct 31, 2017, at 9:42 AM, Davide Italiano wrote:
>
> On Tue, Oct 31, 2017 at 8:59 AM, Greg Clayton via lldb-commits
> wrote:
>> My takeaway is a bug was added that wasn't previously a bug. If code was
>> design
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
A few general things: don't modify FileSpec, we have many of these objects and
we can't increase their size without directly affecting memory usage. FileSpec
objects represent on
On Tue, Oct 31, 2017 at 8:59 AM, Greg Clayton via lldb-commits
wrote:
> My takeaway is a bug was added that wasn't previously a bug. If code was
> designed to carefully use StringRef, then yes, it can be made safe. But we
> added StringRef support in all of LLDB and we didn't catch all of the
> po
This is a case where I think a new API *would* be warranted. But it would
not be an API specifically for the -m option. It would instead be an API
that introduces an `SBBreakpointOptions` class, and then add a method
called `BreakpointCreateWithOptions(options)`.
Note that the general policy of
On Tue, Oct 31, 2017 at 9:00 AM Greg Clayton wrote:
> My main questions is: is there anything we can do to catch these things
> now that we have them.
>
Absolutely. Get bots running check-lldb with ASAN instrumented LLDB. I'm
going to go out on a limb and say you will find not just these bugs,
My takeaway is a bug was added that wasn't previously a bug. If code was
designed to carefully use StringRef, then yes, it can be made safe. But we
added StringRef support in all of LLDB and we didn't catch all of the possible
misuses. My main questions is: is there anything we can do to catch t
Well, at least the good news is this kind of bug *should* have been caught
had we been using a conformant standard library implementation.
Have you ever tried running the test suite with an ASAN instrumented build
of LLDB? We really should have one ASAN bot for every supported
configuration.
On
libstdc++-4.8
I think the newest versions have a conformant implementation, but I
don't know the full details (I know it was a complicated change
because of the need to maintain binary compatibility).
Our android tests are now runinng lldb-server built with libc++ (which
is how I found the bug).
On Tue, Oct 31, 2017 at 8:20 AM Pavel Labath wrote:
> On 31 October 2017 at 15:12, Zachary Turner via lldb-commits
> wrote:
> > The takeaway from this example is nothing we don't already know. We need
> > better test coverage.
> Actually, this was caught by a test (pretty much all of them), but
Btw, is there a way to pass the '-m' option via the SB API? I'd like to
exclude matches in comments when using BreakpointCreateBySourceRegex.
On Tue, Oct 31, 2017 at 8:26 AM, Don Hinton wrote:
> On Tue, Oct 31, 2017 at 8:22 AM, Zachary Turner
> wrote:
>
>>
>>
>> On Tue, Oct 31, 2017 at 8:12 AM
Author: labath
Date: Tue Oct 31 08:27:19 2017
New Revision: 317004
URL: http://llvm.org/viewvc/llvm-project?rev=317004&view=rev
Log:
Add a "watchpoint" test category and annotate tests appropriately
Most of the watchpoint tests are organized into subtrees, so we can use the
file-based .categories
On Tue, Oct 31, 2017 at 8:22 AM, Zachary Turner wrote:
>
>
> On Tue, Oct 31, 2017 at 8:12 AM Don Hinton wrote:
>
>> There have been a few suggestions that I could just use a script to solve
>> this "problem" -- poor startup performance of clangdiag.
>>
>> However, this patch was not submitted to
On Tue, Oct 31, 2017 at 8:12 AM Don Hinton wrote:
> There have been a few suggestions that I could just use a script to solve
> this "problem" -- poor startup performance of clangdiag.
>
> However, this patch was not submitted to solve a particular problem. It
> was submitted in response to Jim'
It's worth mentioning again that LLVM uses StringRef pretty pervasively and
doesn't have issues. There's nothing fundamentally different about
debuggers that makes StringRefs bad whereas they can be good in other types
of software. If we really wanted to avoid use-after-frees we would pick a
lang
On 31 October 2017 at 15:12, Zachary Turner via lldb-commits
wrote:
> The takeaway from this example is nothing we don't already know. We need
> better test coverage.
Actually, this was caught by a test (pretty much all of them), but
only when building with libc++, as the code was "safe" with lib
The takeaway from this example is nothing we don't already know. We need
better test coverage.
On Tue, Oct 31, 2017 at 8:08 AM Greg Clayton via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> This is one example of how StringRef causes issues because it was adopted
> everywhere. Is there an
There have been a few suggestions that I could just use a script to solve
this "problem" -- poor startup performance of clangdiag.
However, this patch was not submitted to solve a particular problem. It
was submitted in response to Jim's suggestion:
On Mon, Oct 23, 2017 at 6:25 PM, Jim Ingham w
This is one example of how StringRef causes issues because it was adopted
everywhere. Is there any way we can change our functions so we can't run into
this issue? Anything we can learn from this example?
> On Oct 26, 2017, at 9:53 PM, Pavel Labath via lldb-commits
> wrote:
>
> Author: lab
This revision was automatically updated to reflect the committed changes.
Closed by commit rL316997: Fix LLVM_LINK_LLVM_DYLIB build (pr35053) (authored
by labath).
Repository:
rL LLVM
https://reviews.llvm.org/D39246
Files:
lldb/trunk/cmake/LLDBDependencies.cmake
lldb/trunk/scripts/CMakeLi
Author: labath
Date: Tue Oct 31 06:23:19 2017
New Revision: 316997
URL: http://llvm.org/viewvc/llvm-project?rev=316997&view=rev
Log:
Fix LLVM_LINK_LLVM_DYLIB build (pr35053)
Summary:
r316368 broke this build when it introduced a reference to a pthread
function to the Utility module. This caused c
This revision was automatically updated to reflect the committed changes.
Closed by commit rL316992: Add data formatter for libc++'s forward_list
(authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D35556?vs=120491&id=120961#toc
Repository:
rL LLVM
https://reviews.llvm.o
Author: labath
Date: Tue Oct 31 05:27:46 2017
New Revision: 316993
URL: http://llvm.org/viewvc/llvm-project?rev=316993&view=rev
Log:
Increase AdbClient read timeout
The previous value was not sufficient for Pixel 2 phones. One would have
hoped that the newer phones are faster, but that does not s
Author: labath
Date: Tue Oct 31 05:27:43 2017
New Revision: 316992
URL: http://llvm.org/viewvc/llvm-project?rev=316992&view=rev
Log:
Add data formatter for libc++'s forward_list
Summary:
This adds a data formatter for the implementation of forward_list in
libc++. I've refactored the existing std:
labath added a comment.
Thanks.
By the way, I have a couple of other patches lined up that you probably did not
notice:
https://reviews.llvm.org/D35666
https://reviews.llvm.org/D35615
https://reviews.llvm.org/D35305
https://reviews.llvm.org/D35556
___
Author: labath
Date: Tue Oct 31 04:48:33 2017
New Revision: 316990
URL: http://llvm.org/viewvc/llvm-project?rev=316990&view=rev
Log:
Fix mac build broken in r316987
Forgot one occurence of ArchSpec::SetTriple in mac-specific code.
Modified:
lldb/trunk/source/Plugins/Process/mach-core/Process
This revision was automatically updated to reflect the committed changes.
Closed by commit rL316987: Invert ArchSpec<->Platform dependency (authored by
labath).
Changed prior to commit:
https://reviews.llvm.org/D39387?vs=120714&id=120957#toc
Repository:
rL LLVM
https://reviews.llvm.org/D393
Author: labath
Date: Tue Oct 31 03:56:03 2017
New Revision: 316987
URL: http://llvm.org/viewvc/llvm-project?rev=316987&view=rev
Log:
Invert ArchSpec<->Platform dependency
Summary:
ArchSpec::SetTriple was taking a Platform as an argument, and used it to
fill in missing pieces of the specified trip
Author: labath
Date: Tue Oct 31 03:33:03 2017
New Revision: 316985
URL: http://llvm.org/viewvc/llvm-project?rev=316985&view=rev
Log:
Android.rules: build with "unified android headers"
Unified headers will be the only way to build applications in NDK r16,
and it also works with NDK r15.
This als
Author: labath
Date: Tue Oct 31 03:01:30 2017
New Revision: 316982
URL: http://llvm.org/viewvc/llvm-project?rev=316982&view=rev
Log:
Split makefile for TestTopLevelExprs
this test was using a single makefile to build two executables. This
setup, although not supported by Makefile.rules, happened
39 matches
Mail list logo
