On Thu, Nov 30, 2017 at 7:41 PM, Jim Ingham via lldb-commits
wrote:
> Author: jingham
> Date: Thu Nov 30 19:41:30 2017
> New Revision: 319516
>
> URL: http://llvm.org/viewvc/llvm-project?rev=319516&view=rev
> Log:
> ClangASTContext::ParseClassTemplateDecl doesn't always succeed.
> When it does, it
Author: jingham
Date: Thu Nov 30 19:41:30 2017
New Revision: 319516
URL: http://llvm.org/viewvc/llvm-project?rev=319516&view=rev
Log:
ClangASTContext::ParseClassTemplateDecl doesn't always succeed.
When it does, it returns a NULL ClassTemplateDecl. Don't use
it if it is NULL...
Modified:
Author: zturner
Date: Thu Nov 30 16:52:51 2017
New Revision: 319504
URL: http://llvm.org/viewvc/llvm-project?rev=319504&view=rev
Log:
Add lldb-test.
This is basically a proof-of-concept and starting point for having a
testing-centric tool in LLDB. I'm sure this leaves a lot of room to be
desired
This revision was automatically updated to reflect the committed changes.
Closed by commit rL319504: Add lldb-test. (authored by zturner).
Changed prior to commit:
https://reviews.llvm.org/D40636?vs=124960&id=125052#toc
Repository:
rL LLVM
https://reviews.llvm.org/D40636
Files:
lldb/trunk
davide accepted this revision.
davide added a comment.
This revision is now accepted and ready to land.
This LGTM. I think we can iterate in tree from what we have.
https://reviews.llvm.org/D40636
___
lldb-commits mailing list
lldb-commits@lists.llv
Author: jmolenda
Date: Thu Nov 30 15:31:18 2017
New Revision: 319500
URL: http://llvm.org/viewvc/llvm-project?rev=319500&view=rev
Log:
We had a situation where a kext was inlined into the kernel,
but still listed in the kernel's kext table with the kernel
binary UUID. This resulted in the kernel
Author: alexshap
Date: Thu Nov 30 14:56:11 2017
New Revision: 319492
URL: http://llvm.org/viewvc/llvm-project?rev=319492&view=rev
Log:
[lldb] A few minor fixes in TaskPool
1. Move TaskPool into the namespace lldb_private.
2. Add missing std::move in TaskPoolImpl::Worker.
3. std::thread::hardware_
This revision was automatically updated to reflect the committed changes.
Closed by commit rL319492: [lldb] A few minor fixes in TaskPool (authored by
alexshap).
Changed prior to commit:
https://reviews.llvm.org/D40587?vs=124661&id=125036#toc
Repository:
rL LLVM
https://reviews.llvm.org/D40
Author: jingham
Date: Thu Nov 30 12:43:00 2017
New Revision: 319472
URL: http://llvm.org/viewvc/llvm-project?rev=319472&view=rev
Log:
Fix this test so that the breakpoints you set are
unambiguously on one bit of code. On macOS these
lines mapped to two distinct locations, and that
was artificiall
jankratochvil added a comment.
In https://reviews.llvm.org/D40475#940462, @labath wrote:
> It looks like it could be a fun project to reimplement `dwz` on top of llvm
> dwarf library, but I understand that would be a considerable detour for you.
I think it would be best to drop DWZ, IIRC its g
The other way to do this would be to pass num_expected_locations = -1 when you
make the foo breakpoint, and then grab the breakpoint's number of locations and
assume you are going to hit the breakpoint that many times.
But changing the code so that the line you are breaking on is unambiguously o
This test actually almost succeeds on macOS. The problem is that your
breakpoint in the Foo constructor produces two line table entries so we hit the
foo breakpoint twice. If you change the test file to:
Index:
packages/Python/lldbsuite/test/functionalities/breakpoint/global_constructor/foo.c
zturner added a comment.
In https://reviews.llvm.org/D40475#935615, @labath wrote:
> The thing to be aware of with this testing strategy is that you will probably
> be the only person who will be able to run these tests and verify dwz
> functionality. If you don't setup a buildbot testing this
We had a similar problem with the tests on macOS. lldb has a facility that
will do automatic lookup of UUID -> dSYM (macOS's separate debug info format)
and if you are internal to Apple this will find all the system library debug
info. That will cause a handful of tests to fail, mostly because
davide added a comment.
@jankratochvil I run Fedora for now on my desktop, but I don't have time and
resources to devote to a buildbot.
IMHO, having a fedora bot would be a great thing for two reasons:
1. I found out Fedora exposes bugs that ubuntu doesn't (e.g. in symbol
resolution, due to sli
Author: jingham
Date: Thu Nov 30 10:35:35 2017
New Revision: 319454
URL: http://llvm.org/viewvc/llvm-project?rev=319454&view=rev
Log:
Remove a long out-of-date comment.
Modified:
lldb/trunk/source/Target/Process.cpp
Modified: lldb/trunk/source/Target/Process.cpp
URL:
http://llvm.org/viewvc/
zturner updated this revision to Diff 124960.
zturner added a comment.
Updated based on labath@'s suggestions. Also added a new class `LinePrinter`,
shamelessly ripped and stripped down from a copy used in one of LLVM's dumpers,
but that makes it possible to do some nice formatting easily.
ht
zturner added inline comments.
Comment at: lit/Modules/compressed-sections.yaml:1
+# REQUIRES: zlib
+# RUN: yaml2obj %s > %t
labath wrote:
> It's right here. (I'm open to suggestions where to place it).
I see. I think part of the reason I didn't notice it is bec
alexandreyy updated this revision to Diff 124952.
alexandreyy added a comment.
Add SIToFP and UIToFP instructions to handle comparisons between float and char
values.
https://reviews.llvm.org/D40647
Files:
source/Expression/IRInterpreter.cpp
Index: source/Expression/IRInterpreter.cpp
==
Author: labath
Date: Thu Nov 30 07:39:57 2017
New Revision: 319443
URL: http://llvm.org/viewvc/llvm-project?rev=319443&view=rev
Log:
Add a test case for open bug 35480
The test is about failing to hit breakpoints in global constructors in
shared libraries.
Added:
lldb/trunk/packages/Python/
labath added inline comments.
Comment at: lit/Modules/compressed-sections.yaml:1
+# REQUIRES: zlib
+# RUN: yaml2obj %s > %t
It's right here. (I'm open to suggestions where to place it).
https://reviews.llvm.org/D40616
Did you forget to add the new test to the changeset?
On Thu, Nov 30, 2017 at 6:19 AM Pavel Labath wrote:
> I have to say I quite like how this test turned out to look like. In
> terms of the last night's SBAPI vs. lldb-mi vs. whateever discussion,
> i'd can say that there is nothing preventing th
labath added a comment.
In https://reviews.llvm.org/D40475#940226, @jankratochvil wrote:
> > you will probably be the only person who will be able to run these tests
> > and verify dwz functionality.
>
> OK; really nobody runs RHEL/CentOS/Fedora? :-)
There aren't that many lldb developers... I
I have to say I quite like how this test turned out to look like. In
terms of the last night's SBAPI vs. lldb-mi vs. whateever discussion,
i'd can say that there is nothing preventing this test written in
terms of the SB API. I didn't do it that way, because I have
automatically written the test at
jankratochvil marked 2 inline comments as done.
jankratochvil added inline comments.
Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h:487
+ public:
+// C++14: Use heterogenous lookup.
+DWZCommonFile(const lldb_private::FileSpec &filespec_ref);
--
labath updated this revision to Diff 124926.
labath added a comment.
This rewrites the test in terms on the new lldb-test utility. It should be
applied on top of https://reviews.llvm.org/D40636.
While doing that, I noticed a discrepancy in the data presented by the object
file interface -- for G
You’re right that it’s basically reimplementing readobj but as you said, we
have our own object file readers. More importantly though, even if we
delegated to llvm, something could still in theory go wrong in the Module
class.
Plus, the important thing part of this patch is not this one module
com
alexandreyy created this revision.
Implemented FCmp and FPExt instructions.
https://reviews.llvm.org/D40647
Files:
source/Expression/IRInterpreter.cpp
Index: source/Expression/IRInterpreter.cpp
===
--- source/Expression/IRInterp
labath added a comment.
I feel this is reimplementing llvm-readobj, but maybe that's appropriate as we
are reimplementing object file readers as well (my original patch wouldn't be
necessary if we were using the llvm object library). Minor comments below, but
I actually quite like this approach
This revision was automatically updated to reflect the committed changes.
Closed by commit rL319414: Fix assertion in ClangASTContext (authored by
labath).
Changed prior to commit:
https://reviews.llvm.org/D40615?vs=124781&id=124890#toc
Repository:
rL LLVM
https://reviews.llvm.org/D40615
F
Author: labath
Date: Thu Nov 30 02:16:54 2017
New Revision: 319414
URL: http://llvm.org/viewvc/llvm-project?rev=319414&view=rev
Log:
Fix assertion in ClangASTContext
Summary:
llvm::APSInt(0) asserts because it creates an int with bit-width 0 and
not (as I thought) a value 0.
Theoretically it sho
jankratochvil added a comment.
> you will probably be the only person who will be able to run these tests and
> verify dwz functionality.
OK; really nobody runs RHEL/CentOS/Fedora? :-)
> If you don't setup a buildbot testing
OK, I will try that. I was even running a test bot for GDB.
> These
labath marked an inline comment as done.
labath added inline comments.
Comment at: include/lldb/Symbol/CompilerType.h:294
+ struct IntegralTemplateArgument;
+
clayborg wrote:
> Can't you just define the type right here?
Unfortunately, I can't because it contai
jankratochvil added a comment.
> Please undo all renaming from offset to file_offset.
I am preparing now a split of this patch for the renaming part + the "real"
part, sorry I did not realize it is mostly about the renaming which is not
worth your detailed review.
There are two different types
34 matches
Mail list logo
