labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
Ok, let's give this a try.
https://reviews.llvm.org/D46726
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bi
This probably isn't what was happening here because you would have seen the
extra stops in the logs, but one way I can think of we can end up at the
same PC is if the process gets a signal while we're about to single-step
it, in which case we need to execute the signal handler first and then get
ba
labath added a comment.
Changing the code to filter based on the dwarf information instead of the going
through CompilerDeclContexts sounds like a good idea. I've been wondering why
we are doing it this way -- the explanation I gave to myself was that this
would allow the individual language pl
Author: labath
Date: Tue May 22 09:33:43 2018
New Revision: 332997
URL: http://llvm.org/viewvc/llvm-project?rev=332997&view=rev
Log:
Enable ProcessMachCore plugin on non-apple platforms
Summary:
The plugin already builds fine on other platforms (linux, at least). All
that was necessary was to rev
I haven't played around with this yet. Can it also provide enough memory to
pretend a stack trace? Most of the thread plan stuff will fall over pretty
early if it doesn't have at least a couple of frames?
Jim
> On May 22, 2018, at 2:41 AM, Pavel Labath wrote:
>
> This probably isn't what w
This revision was automatically updated to reflect the committed changes.
Closed by commit rL332997: Enable ProcessMachCore plugin on non-apple platforms
(authored by labath, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://reviews.llvm.org/D47133
Files:
BTW, I think it is likely that we are being interrupted, but the bug happens
very infrequently and generally goes away when I turn on more than a trivial
amount of logging, so it's been hard to prove that yet.
Jim
> On May 22, 2018, at 9:37 AM, Jim Ingham wrote:
>
> I haven't played around w
> > On May 22, 2018, at 9:37 AM, Jim Ingham wrote:
> >
> > I haven't played around with this yet. Can it also provide enough
memory to pretend a stack trace? Most of the thread plan stuff will fall
over pretty early if it doesn't have at least a couple of frames?
You can do anything, but there
This change has introduced a dependency from Core -> clang Driver (due to
#include "clang/Driver/Driver.h" in ModuleList.cpp). Can you please try to
find a way to remove this dependency?
On Fri, Mar 2, 2018 at 2:45 PM Phabricator via Phabricator via lldb-commits
wrote:
> This revision was not a
zturner added subscribers: aprantl, labath, zturner.
zturner added a comment.
This change has introduced a dependency from Core -> clang Driver (due to
#include "clang/Driver/Driver.h" in ModuleList.cpp). Can you please try to
find a way to remove this dependency?
Repository:
rL LLVM
https:/
Can you help me understand why this dependency poses a problem? It's not clear
to me how to resolve this otherwise. The point of the patch is to ask the clang
driver for the clang module cache path. If the problem is that we otherwise
don't use the driver and now pull it in, would moving the Cla
We've been going to a lot of effort recently to separate out dependencies
and properly layer libraries. Even if we deemed this to be an acceptable
location to #include something from clang/Driver, the CMake does not
actually reference clangDriver in its link list. So the only reason this
is worki
Where clang stores modules by default on the host system seems like a Host
function. It isn't in practice because that gets delegated to clang to do the
host specific calculation, but in theory that seems where the functionality
properly belongs. It's a little odd to have ModuleList depend on
zturner created this revision.
zturner added reviewers: labath, jingham.
Herald added a subscriber: mgorny.
This was responsible for the cycle Core > ObjectFile > Core.
The only reason this dependency was here was so that `Module` could have a
function called `CreateJITModule` which created thin
Author: jyknight
Date: Tue May 22 14:49:41 2018
New Revision: 333032
URL: http://llvm.org/viewvc/llvm-project?rev=333032&view=rev
Log:
Avoid using header from Host/macosx when not testing an apple build.
Modified:
lldb/trunk/unittests/Host/HostInfoTest.cpp
Modified: lldb/trunk/unittests/Host
zturner created this revision.
zturner added reviewers: labath, davide.
The REPL (which lives in Expression) was making use of the command options for
the expression command. It's arguable whether `REPL` should even live in
`Expression` to begin with, but it makes more sense for Command to depe
Author: jyknight
Date: Tue May 22 15:53:50 2018
New Revision: 333035
URL: http://llvm.org/viewvc/llvm-project?rev=333035&view=rev
Log:
Normalize some lldb #include statements.
Most non-local includes of header files living under lldb/sources/
were specified with the full path starting after sourc
davide accepted this revision.
davide added a comment.
This revision is now accepted and ready to land.
Looks fine to me, but let's wait for Pavel. Are you back working on lldb ? :)
https://reviews.llvm.org/D47232
___
lldb-commits mailing list
lldb-
Author: compnerd
Date: Tue May 22 16:24:46 2018
New Revision: 333041
URL: http://llvm.org/viewvc/llvm-project?rev=333041&view=rev
Log:
build: use cmake to find the libedit content
Use proper cmake techniques to detect where the libedit package resides.
This allows for the use of libedit from an a
compnerd closed this revision.
compnerd added a comment.
SVN r333041
https://reviews.llvm.org/D46726
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
aprantl created this revision.
aprantl added reviewers: zturner, jingham.
Herald added subscribers: jkorous, MaskRay, ioeric, ilya-biryukov, mgorny.
@zturner wrote:
> This change has introduced a dependency from Core -> clang Driver (due to
> #include "clang/Driver/Driver.h" in ModuleList.cpp).
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
The REPL is just a mode of the expression command. You invoke it by saying:
(lldb) expr --repl --
or you can add any other options to it that you want, including flags like -i
or
jingham added a comment.
Perhaps a better way to handle this is to think of REPL.cpp/h as adjuncts of
CommandObjectExpression.cpp/h - they mostly define the fancy IOHandler that
gets pushed when you run the command in this mode. I think it would be fine to
move them to Command, at which point
This revision was not accepted when it landed; it landed in state "Needs
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL333049: [SymbolFilePDB] Add support for resolving variable
symbols (authored by asmith, committed by ).
Changed prior to
zturner added a subscriber: aprantl.
zturner added a comment.
Yea I don’t think this addresses the problem. We should be able to link
against parts of lldb without a dependency on clang. Since this is about
configuring something related to clang, it seems like it should be isolated
to some part of
Yea I don’t think this addresses the problem. We should be able to link
against parts of lldb without a dependency on clang. Since this is about
configuring something related to clang, it seems like it should be isolated
to some part of lldb that interfaces with clang
On Tue, May 22, 2018 at 4:32 P
26 matches
Mail list logo