I'm not familiar with all of the magic we do when we synthesize clang
Decls, but I feel I should point out that we can't get out of business of
sanity-checking the declarations we inject into clang. The reason for that
is, even if we had debug info for operator==, the debug info itself could
descri
Author: labath
Date: Wed Mar 14 02:13:33 2018
New Revision: 327483
URL: http://llvm.org/viewvc/llvm-project?rev=327483&view=rev
Log:
Skip TestWatchedVarHitWhenInScope.py everywhere
The expression-hits tracking logic is not available on any platform. The
reason this tests happens to pass on some p
labath added inline comments.
Comment at: cmake/modules/LLDBConfig.cmake:349
-if (HAVE_LIBPTHREAD)
- list(APPEND system_libs pthread)
-endif(HAVE_LIBPTHREAD)
-
-if (HAVE_LIBDL)
- list(APPEND system_libs ${CMAKE_DL_LIBS})
+if(UNIX)
+ set(CMAKE_THREAD_PREFER_PTHREAD TRUE)
Author: labath
Date: Wed Mar 14 03:08:21 2018
New Revision: 327490
URL: http://llvm.org/viewvc/llvm-project?rev=327490&view=rev
Log:
[cmake] Fix standalone+LLVM_LINK_LLVM_DYLIB builds (pr36687)
Summary:
To make this build work, I needed to add detection code for the pthread
library. This is neces
This revision was automatically updated to reflect the committed changes.
Closed by commit rL327490: [cmake] Fix standalone+LLVM_LINK_LLVM_DYLIB builds
(pr36687) (authored by labath, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D4437
Author: jdevlieghere
Date: Wed Mar 14 04:50:10 2018
New Revision: 327501
URL: http://llvm.org/viewvc/llvm-project?rev=327501&view=rev
Log:
Update selected thread after loading mach core
The OS plugins might have updated the thread list after a core file has
been loaded. The physical thread in the
This revision was automatically updated to reflect the committed changes.
Closed by commit rL327501: Update selected thread after loading mach core
(authored by JDevlieghere, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D44139?vs=137993&id=138331#toc
Repository:
rL LLVM
JDevlieghere added a comment.
In https://reviews.llvm.org/D44139#1036521, @jasonmolenda wrote:
> (or rather, not "conflict with the OperatingSystemPlugIn stop reason" -- but
> would make it confusing to users. I think it might be best to remove
> ThreadMachCore::CalculateStopInfo.)
Sounds re
Author: jdevlieghere
Date: Wed Mar 14 07:16:23 2018
New Revision: 327512
URL: http://llvm.org/viewvc/llvm-project?rev=327512&view=rev
Log:
[test] Disable TestMachCore everywhere except on Darwin
Apparently the parser is wrapped inside ifdef's so the logic isn't
available on non-Darwin platforms.
JDevlieghere created this revision.
JDevlieghere added reviewers: davide, labath, zturner.
Herald added subscribers: llvm-commits, mgorny.
This makes llvm-dotest a custom target so you can run `ninja
llvm-dotest` to rebuild whatever is necessary before rerunning the
tests.
Repository:
rL LLVM
davide accepted this revision.
davide added a comment.
This revision is now accepted and ready to land.
LGTM
Repository:
rL LLVM
https://reviews.llvm.org/D44473
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-b
Shouldn’t it be lldb-dotest? I’m confused about what this target does
On Wed, Mar 14, 2018 at 8:21 AM Davide Italiano via Phabricator <
revi...@reviews.llvm.org> wrote:
> davide accepted this revision.
> davide added a comment.
> This revision is now accepted and ready to land.
>
> LGTM
>
>
> Repo
zturner added a subscriber: JDevlieghere.
zturner added a comment.
Shouldn’t it be lldb-dotest? I’m confused about what this target does
Repository:
rL LLVM
https://reviews.llvm.org/D44473
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
davide added a comment.
Also, I second the feeling of having `lldb` somewhere in the name for the
utility (rather than `llvm` :)
Repository:
rL LLVM
https://reviews.llvm.org/D44473
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http:/
davide added a comment.
The name should be changed (also the utility name), but that should be done
separately.
Repository:
rL LLVM
https://reviews.llvm.org/D44473
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/c
JDevlieghere updated this revision to Diff 138370.
JDevlieghere added a comment.
Yeah, that's more sensible indeed. I must have had `llvm-lit` in mind and never
gave it a second thought.
Repository:
rL LLVM
https://reviews.llvm.org/D44473
Files:
test/CMakeLists.txt
test/lldb-dotest.in
Author: jdevlieghere
Date: Wed Mar 14 08:36:32 2018
New Revision: 327519
URL: http://llvm.org/viewvc/llvm-project?rev=327519&view=rev
Log:
[dotest] Rename llvm-dotest -> lldb-dotest and make it a custom target
This renames llvm-dotest to lldb-dotest and makes it a custom target so
you can run `ni
This revision was automatically updated to reflect the committed changes.
Closed by commit rL327519: [dotest] Rename llvm-dotest -> lldb-dotest and
make it a custom target (authored by JDevlieghere, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D44473?vs=138370&id=138372#toc
What part is ifdef'ed? Mach core files should be available on any platform?
> On Mar 14, 2018, at 7:16 AM, Jonas Devlieghere via lldb-commits
> wrote:
>
> Author: jdevlieghere
> Date: Wed Mar 14 07:16:23 2018
> New Revision: 327512
>
> URL: http://llvm.org/viewvc/llvm-project?rev=327512&view=r
Take a look at #ifdef __APPLE__ around ObjectFileMachO in
SystemInitializerCommon.cpp.
I tried removing that, but that led to a bunch of undefined symbol errors
(because of other stuff that was ifdefed out). It could be this is just a
matter of removing enough ifdefs, but I haven't tried following
labath updated this revision to Diff 138418.
labath added a comment.
Herald added a subscriber: mgorny.
This is a version that moves the StringTo*** functions to a new
"OptionArgParser" class. I'm not terribly proud of the name, but I couldn't
think of anything better -- we already have a OptionPa
That shouldn't be there. Lets remove it and see how things go.
> On Mar 14, 2018, at 10:30 AM, Pavel Labath wrote:
>
> Take a look at #ifdef __APPLE__ around ObjectFileMachO in
> SystemInitializerCommon.cpp.
>
> I tried removing that, but that led to a bunch of undefined symbol errors
> (bec
That might have been there from before when we might have used system headers
for the mach-o stuff. That was a way long time ago. We now use LLVM's headers
for everything so it should be safe.
> On Mar 14, 2018, at 11:29 AM, Greg Clayton wrote:
>
> That shouldn't be there. Lets remove it and s
jingham added a comment.
Except for the to -> To to keep consistent with all the other lldb function
naming this looks fine.
Now that they are all together it's easy to see we haven't been consistent in
these functions. We really should make ToFormat return the format & take an
error referenc
I think having all parsing functions in a single place will just move the
layering problem elsewhere, since a bunch of conversion functions for
objects from various libraries will be mushed together into one place.
On Wed, Mar 14, 2018 at 11:34 AM Jim Ingham via Phabricator <
revi...@reviews.llvm.
Author: vedantk
Date: Wed Mar 14 11:37:13 2018
New Revision: 327552
URL: http://llvm.org/viewvc/llvm-project?rev=327552&view=rev
Log:
[test] Delete some xfailed lldb-mi tests
This is a first pass at removing some lldb-mi tests which have been
xfailed and unmaintained for a while. We have open PRs
zturner added a subscriber: labath.
zturner added a comment.
I think having all parsing functions in a single place will just move the
layering problem elsewhere, since a bunch of conversion functions for
objects from various libraries will be mushed together into one place.
https://reviews.llvm
jingham added a comment.
As long as these functions are used for parsing options args in individual
CommandObject implementations, and don't get dragged lower in the stack, I
don't think that's a problem. By the time you're getting to individual
commands you are on top of pretty much everythin
labath added a comment.
I agree with Jim. I deliberately put here only the types that are used for
command parsing, since I presume these are the things that the
Command/Interpreter modules will depend on (it's not fully clear to me where to
draw the line between these two, so it may end up nee
Author: vedantk
Date: Wed Mar 14 13:32:10 2018
New Revision: 327568
URL: http://llvm.org/viewvc/llvm-project?rev=327568&view=rev
Log:
[test] Skip some lldb-mi tests which time out on Darwin
These don't always timeout, but it's inconvenient when they do.
Modified:
lldb/trunk/packages/Python/
Author: vedantk
Date: Wed Mar 14 15:52:32 2018
New Revision: 327586
URL: http://llvm.org/viewvc/llvm-project?rev=327586&view=rev
Log:
[test] Skip more lldb-mi tests which occasionally time out on Darwin
Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiVar.py
timotheecour updated this revision to Diff 138471.
timotheecour added a comment.
- added d_terminate
- format
https://reviews.llvm.org/D44321
Files:
include/lldb/Core/Mangled.h
include/lldb/Core/PluginManager.h
source/API/SystemInitializerFull.cpp
source/Core/CMakeLists.txt
source/Cor
Author: davide
Date: Wed Mar 14 16:09:36 2018
New Revision: 327587
URL: http://llvm.org/viewvc/llvm-project?rev=327587&view=rev
Log:
[DataFormatters] Implement summary for __NSDictionary0.
Before the patch:
(lldb) frame var emptyDictionary
(__NSDictionary0 *) emptyDictionary = 0x000100304420
timotheecour added a comment.
> How do you de-initialize druntime? (without de-init, there is a big mem leak)
There is no memory leak because `d_initialize` once (using c++11 static
initialization pattern) and is intended to last for duration of application; so
druntime will be initialized only
clayborg created this revision.
clayborg added reviewers: jingham, labath, lldb-commits.
When using:
(lldb) settings set target.source-map ./ /path/to/source
LLDB would fail to set a source file and line breakpoint with:
(lldb) breakpoint set --file /path/to/source/main.c --line 2
Because
johanengelen added a comment.
In https://reviews.llvm.org/D44321#1038160, @timotheecour wrote:
> > How do you de-initialize druntime? (without de-init, there is a big mem
> > leak)
>
> There is no memory leak because `d_initialize` once (using c++11 static
> initialization pattern) and is inten
clayborg added a comment.
The DWARF file that this produces has a DW_AT_comp_dir set to ".". This is
similar to how some builds work at Facebook when using Buck to build things.
https://reviews.llvm.org/D44502
___
lldb-commits mailing list
lldb-com
timotheecour added a comment.
> When druntime is initialized, a number of resources are allocated (e.g.
> memory and mutex). Yes you initialize druntime once, I can see that. You
> don't deinitialize druntime at all: that's the resource leak.
Where would you want me to deinit? inside ` DLanguag
timotheecour added inline comments.
Comment at: source/Plugins/Language/D/DLanguage.cpp:108
+
+auto fun0=lib2->getFun("d_initialize");
+(*fun0)();
johanengelen wrote:
> timotheecour wrote:
> > johanengelen wrote:
> > > Would it help to initialize druntime
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
This seems clearly right to me. Thanks for the test.
https://reviews.llvm.org/D44502
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
davide added a comment.
(please wait a day or two if @labath has comments) but this should be fine.
https://reviews.llvm.org/D44502
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
davide accepted this revision.
davide added a comment.
LGTM, thanks
https://reviews.llvm.org/D44502
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
timotheecour updated this revision to Diff 138477.
timotheecour added a comment.
- fix assert fail when plugin.language.D.pluginfile empty
https://reviews.llvm.org/D44321
Files:
include/lldb/Core/Mangled.h
include/lldb/Core/PluginManager.h
source/API/SystemInitializerFull.cpp
source/Cor
Author: davide
Date: Wed Mar 14 17:07:05 2018
New Revision: 327592
URL: http://llvm.org/viewvc/llvm-project?rev=327592&view=rev
Log:
[Dictionary] Rewrite the test added in r327587 as an inline test.
Until we have a better story for putting commands and check lines
in the same file (they're curren
Author: vedantk
Date: Wed Mar 14 18:09:13 2018
New Revision: 327595
URL: http://llvm.org/viewvc/llvm-project?rev=327595&view=rev
Log:
[test] cmake: Ensure liblldb builds before tests run
Without liblldb as a test dependency, tests which link it in from an
lldb framework (via Base.buildDriver()) w
Author: gclayton
Date: Wed Mar 14 22:13:15 2018
New Revision: 327600
URL: http://llvm.org/viewvc/llvm-project?rev=327600&view=rev
Log:
Fix a bug in "target.source-map" where we would resolve unmapped paths
incorrectly
When using:
(lldb) settings set target.source-map ./ /path/to/source
LLDB wou
clayborg added a comment.
Committed revision 327600.
https://reviews.llvm.org/D44502
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL327600: Fix a bug in "target.source-map" where we
would resolve unmapped paths… (authored by gclayton, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.l
xiaobai created this revision.
xiaobai added reviewers: vsk, beanz.
Herald added a subscriber: mgorny.
Instead of building debugserver when building lldb, I'd rather pass
LLDB_CODESIGN_IDENTITY="" to cmake and use the one already on my system.
However, on one of my machines I only have the Command
49 matches
Mail list logo
