ted added a comment.
We build lldb, clang and tools for Hexagon only, and call them hexagon-lldb,
hexagon-clang, etc. The test infrastructure is smart enough to pick up
hexagon-lldb-mi if we tell it to run with hexagon-lldb using --executable; will
it be smart enough to run an in-tree hexagon-c
zturner added a comment.
In https://reviews.llvm.org/D39215#905259, @ted wrote:
> We build lldb, clang and tools for Hexagon only, and call them hexagon-lldb,
> hexagon-clang, etc. The test infrastructure is smart enough to pick up
> hexagon-lldb-mi if we tell it to run with hexagon-lldb using
Author: labath
Date: Tue Oct 24 09:07:50 2017
New Revision: 316451
URL: http://llvm.org/viewvc/llvm-project?rev=316451&view=rev
Log:
Revert "[lldbtests] Handle errors instead of crashing."
The commit breaks the case where you specify just a filename to the
compiler. Previously, it would look up t
HI, I'm a little curious of what bot this breaks.
FWIW, I don't think the bot should rely on this behaviour, and more
importantly, I haven't received any failmail.
Thanks,
--
Davide
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.
labath added a comment.
Davide, I reverted this because it breaks the case when you just specify a
filename as a compiler (with the expectation that we will look it up in the
path). I think this is a good thing to have, and our buildbot was using that
behavior.
I like the direction this change
(and thanks for reverting, BTW :)
On Tue, Oct 24, 2017 at 9:10 AM, Davide Italiano wrote:
> HI, I'm a little curious of what bot this breaks.
> FWIW, I don't think the bot should rely on this behaviour, and more
> importantly, I haven't received any failmail.
>
> Thanks,
>
> --
> Davide
_
I think there's something like lit.util.which(), or a similar function in
lldb test utilities. Seems like we could solve this by writing the
function:
```
def is_exe(fpath):
if not os.path.exists(fpath):
fpath = lit.util.which(fpath)
if not (fpath and os.path.exists(fpath)):
On Tue, Oct 24, 2017 at 9:12 AM, Zachary Turner via lldb-commits
wrote:
> I think there's something like lit.util.which(), or a similar function in
> lldb test utilities. Seems like we could solve this by writing the
> function:
>
> ```
> def is_exe(fpath):
>if not os.path.exists(fpath):
>
On 24 October 2017 at 08:58, Ted Woodward via Phabricator
wrote:
> ted added a comment.
>
> We build lldb, clang and tools for Hexagon only, and call them hexagon-lldb,
> hexagon-clang, etc. The test infrastructure is smart enough to pick up
> hexagon-lldb-mi if we tell it to run with hexagon-ll
The breaking build is this one: <
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/14775>
The blame email was sent (I know because I got it, as I also had a
commit in the same build). Is it possible you overlooked it?
```
def is_exe(fpath):
if not os.path.exists(fpath):
On Tue, Oct 24, 2017 at 9:25 AM, Pavel Labath wrote:
> The breaking build is this one: <
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/14775>
>
> The blame email was sent (I know because I got it, as I also had a
> commit in the same build). Is it possible you overlooke
Fun fact, there are 13 implementations in tree of is_exe (and probably
which). Maybe we should try replacing all them with the one from lit?
Or is there some hidden dependency I'm missing?
[davide@cupiditate lldb]$ grep -R 'def is_exe' *
packages/Python/lldbsuite/test/dotest.py:def is_exe(fpath):
Actually there's fewer, I think `test/testcases` is a symlink. But there's
more than one, for sure. We should standardize on the one in lldbutil.py
On Tue, Oct 24, 2017 at 9:33 AM Davide Italiano
wrote:
> Fun fact, there are 13 implementations in tree of is_exe (and probably
> which). Maybe we
Reported https://bugs.llvm.org/show_bug.cgi?id=35061 so I don't forget.
On Tue, Oct 24, 2017 at 9:35 AM, Zachary Turner wrote:
> Actually there's fewer, I think `test/testcases` is a symlink. But there's
> more than one, for sure. We should standardize on the one in lldbutil.py
>
> On Tue, Oct
labath created this revision.
Herald added a subscriber: mgorny.
r316368 broke this build when it introduced a reference to a pthread
function to the Utility module. This caused cmake to generate an
incorrect link line (wrong order of libs) because it did not see the
dependency from Utility to the
labath updated this revision to Diff 120102.
labath added a comment.
This removes the LLDB_TEST_CLANG and LLDB_TEST_COMPILER settings.
I've decided to keep the separate C and CXX variables because:
a) that's consistent with other cmake settings
b) in case of gcc, it's not easy to figure out the c
sylvestre.ledru added a comment.
This fixed the issue, thanks!
https://reviews.llvm.org/D39246
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath added a comment.
I'm back now, and I'd like to try to push this patch to completion.
After re-reading the discussion, I got the impression we have mostly reached a
consensus here. A small issue remained about how to guarantee that the
Architecture plugin and the ArchSpec object are in sy
clayborg accepted this revision.
clayborg added a comment.
Looks fine. We can iterate on this.
https://reviews.llvm.org/D31172
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Looks fine. We can start with this. I was thinking it would be nice to lazily
populate m_plugin_up, but then we would need to add a bit to see if we already
tried to look for it, so the current approach will work fine.
> On Oct 24, 2017, at 1:22 PM, Pavel Labath via Phabricator
> wrote:
>
> l
zturner added a comment.
I know you're doing things the way it's always been done, but I want to start
questioning some long-standing practices :) So I'm not picking on you
specifically, but anywhere we can migrate towards something better
incrementally, I think we should do so.
===
labath added inline comments.
Comment at: include/lldb/Target/Target.h:1217
+const ArchSpec &GetSpec() const { return m_spec; }
+Architecture *GetPlugin() const { return m_plugin_up.get(); }
+
zturner wrote:
> Can this return a reference instead of a poin
zturner added inline comments.
Comment at: source/Core/PluginManager.cpp:281-282
+struct ArchitectureInstance {
+ ConstString name;
+ std::string description;
+ PluginManager::ArchitectureCreateInstance create_callback;
labath wrote:
> zturner wrote:
> > Why d
clayborg added inline comments.
Comment at: include/lldb/Target/Target.h:1217
+const ArchSpec &GetSpec() const { return m_spec; }
+Architecture *GetPlugin() const { return m_plugin_up.get(); }
+
zturner wrote:
> Can this return a reference instead of a po
zturner added inline comments.
Comment at: source/Core/PluginManager.cpp:281
+struct ArchitectureInstance {
+ ConstString name;
+ std::string description;
zturner wrote:
> labath wrote:
> > clayborg wrote:
> > > zturner wrote:
> > > > Why do we need a `ConstStr
zturner added inline comments.
Comment at: source/Plugins/Architecture/Arm/ArchitectureArm.cpp:23
+ return ConstString("arm");
+}
+
clayborg wrote:
> One time at startup. No threads contending yet. Asking for plug-in by name is
> made fast for later. I would le
clayborg added inline comments.
Comment at: source/Core/PluginManager.cpp:282
+ ConstString name;
+ std::string description;
+ PluginManager::ArchitectureCreateInstance create_callback;
zturner wrote:
> clayborg wrote:
> > We need "std::string" since it owns t
zturner added inline comments.
Comment at: source/Plugins/Architecture/Arm/ArchitectureArm.cpp:23
+ return ConstString("arm");
+}
+
clayborg wrote:
> zturner wrote:
> > clayborg wrote:
> > > One time at startup. No threads contending yet. Asking for plug-in by
clayborg added inline comments.
Comment at: source/Plugins/Architecture/Arm/ArchitectureArm.cpp:23
+ return ConstString("arm");
+}
+
zturner wrote:
> clayborg wrote:
> > zturner wrote:
> > > clayborg wrote:
> > > > One time at startup. No threads contending yet.
jasonmolenda added a comment.
> There was a talk at cppcon a few weeks ago from someone at backtrace.io who
> had some insightful metrics on debugger performance memory consumption, and
> LLDB had ~2x the memory consumption of GDB.
I haven't seen the paper, but my guess is that this is on linux
zturner accepted this revision.
zturner added a comment.
I will ping them for some numbers and more details of their test setup.
Regardless, I didn't mean to derail the code review. But, I really really want
to reach a point where we can stop falling back on the "we need to be safe even
in th
Author: sas
Date: Tue Oct 24 15:56:05 2017
New Revision: 316526
URL: http://llvm.org/viewvc/llvm-project?rev=316526&view=rev
Log:
Remove some dead code from ClangExpressionDeclMap.cpp
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
Modified:
lldb/trunk/
Author: sas
Date: Tue Oct 24 16:01:33 2017
New Revision: 316527
URL: http://llvm.org/viewvc/llvm-project?rev=316527&view=rev
Log:
Remove some unused function calls from ClangUserExpression.cpp
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
Modified:
lldb/
sas updated this revision to Diff 120146.
sas added a comment.
Herald added a subscriber: kristof.beyls.
Rebase.
https://reviews.llvm.org/D19604
Files:
source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
Index: source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
Author: davide
Date: Tue Oct 24 16:29:01 2017
New Revision: 316529
URL: http://llvm.org/viewvc/llvm-project?rev=316529&view=rev
Log:
[ExpressionParser] Garbage-collect dead code. NFCI.
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.cpp
Modified:
lldb/trunk/s
Author: davide
Date: Tue Oct 24 16:31:53 2017
New Revision: 316530
URL: http://llvm.org/viewvc/llvm-project?rev=316530&view=rev
Log:
[FreeBSD] Remove more dead code. NFCI.
Modified:
lldb/trunk/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp
Modified: lldb/trunk/source/Plugins/Process/FreeB
Author: sas
Date: Tue Oct 24 16:40:59 2017
New Revision: 316532
URL: http://llvm.org/viewvc/llvm-project?rev=316532&view=rev
Log:
Allow ObjectFilePECOFF to initialize with ARM binaries.
Summary: This is required to start debugging WinPhone ARM targets.
Reviewers: compnerd, zturner, omjavaid
Rev
This revision was automatically updated to reflect the committed changes.
Closed by commit rL316532: Allow ObjectFilePECOFF to initialize with ARM
binaries. (authored by sas).
Repository:
rL LLVM
https://reviews.llvm.org/D19604
Files:
lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePE
Author: sas
Date: Tue Oct 24 16:46:00 2017
New Revision: 316533
URL: http://llvm.org/viewvc/llvm-project?rev=316533&view=rev
Log:
Fix a compile warning on linux
Can't cast directly between a pointer to function and a pointer to
object.
Modified:
lldb/trunk/source/API/SBDebugger.cpp
Modified
39 matches
Mail list logo
