Author: jingham
Date: Thu Jan 11 19:03:23 2018
New Revision: 322348
URL: http://llvm.org/viewvc/llvm-project?rev=322348&view=rev
Log:
Fix Breakpoint::RemoveInvalidLocations to fix the exec testcase.
RemoveInvalidLocations was clearing out the m_locations in the
breakpoint by hand, and it wasn't a
Author: jingham
Date: Thu Jan 11 17:30:33 2018
New Revision: 322341
URL: http://llvm.org/viewvc/llvm-project?rev=322341&view=rev
Log:
Fix the Makefile - this version should work on the bot
Modified:
lldb/trunk/packages/Python/lldbsuite/test/macosx/find-app-in-bundle/Makefile
Modified:
lldb/
On Thu, Jan 11, 2018 at 5:16 PM, Jason Molenda via lldb-commits
wrote:
> Author: jmolenda
> Date: Thu Jan 11 17:16:13 2018
> New Revision: 322339
>
> URL: http://llvm.org/viewvc/llvm-project?rev=322339&view=rev
> Log:
> When parsing the target.xml register file, if no architecture has
> been speci
Author: vedantk
Date: Thu Jan 11 17:23:52 2018
New Revision: 322340
URL: http://llvm.org/viewvc/llvm-project?rev=322340&view=rev
Log:
Skip TestFunctionTemplateParameterPack.py, which unexpectedly asserts (PR35920)
This test stresses expression evaluation support for template functions.
Currently
Author: jmolenda
Date: Thu Jan 11 17:16:13 2018
New Revision: 322339
URL: http://llvm.org/viewvc/llvm-project?rev=322339&view=rev
Log:
When parsing the target.xml register file, if no architecture has
been specified yet (either by the user, or by one of the lldb
extensions like qHostInfo or qProce
Author: jingham
Date: Thu Jan 11 17:12:45 2018
New Revision: 322338
URL: http://llvm.org/viewvc/llvm-project?rev=322338&view=rev
Log:
Print the SBDebugger.CreateTarget error message.
This is failing on the bot but not locally. Maybe
the error message will tell us why.
Modified:
lldb/trunk/
Author: jingham
Date: Thu Jan 11 15:52:50 2018
New Revision: 322329
URL: http://llvm.org/viewvc/llvm-project?rev=322329&view=rev
Log:
Fix the same thinko in another place...
Thanks Jason.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/macosx/find-app-in-bundle/TestFindAppInBundle.py
Mo
Author: jingham
Date: Thu Jan 11 15:31:29 2018
New Revision: 322328
URL: http://llvm.org/viewvc/llvm-project?rev=322328&view=rev
Log:
Fix a tiny thinko in this test and re-add.
target.IsValid() not target...
Added:
lldb/trunk/packages/Python/lldbsuite/test/macosx/find-app-in-bundle/Makefile
The test Jim committed broke the public bots, so I went ahead and reverted it.
Committing to https://llvm.org/svn/llvm-project/lldb/trunk ...
commit 87eb2de0885d646e71d5848c1fa699b784bf5d2b
Author: Davide Italiano
Date: Thu Jan 11 14:37:49 2018 -0800
[testsuite] Remove a broken test which
Author: davide
Date: Thu Jan 11 14:38:57 2018
New Revision: 322322
URL: http://llvm.org/viewvc/llvm-project?rev=322322&view=rev
Log:
[testsuite] Remove a broken test which tried to find App in bundles.
That never really worked, and the change associated isn't yet
committed, so, let's try to make
clayborg added a comment.
Yeah, the threading was added later. It started out as single threaded and
didn't have this problem.
https://reviews.llvm.org/D41909
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/m
zturner added a comment.
Seems like the high level problem is that the entity which acquires the mutex
is not the same as the entity which decides how data gets into the Module. For
example, we call `SymbolVendor::FindFunctions` and expect that someone is going
to somehow get some functions in
clayborg added a comment.
We will need to pass the mutex down into any call that needs to let the mutex
go. At least that is the only way I could see this working... But then all
functions that do anything lazily will need this same treatment. Lot of trouble
for the logging.
https://reviews.l
fjricci added a comment.
> SymbolVendor::FindFunctions will lazily parse functions from the debug info
> and populate things inside the module, so the lock is required.
Can it give up the lock while it's blocked on worker threads? Holding a lock
while blocked seems like a recipe for deadlocks (
craig.topper added a comment.
I don't know what platforms this needs to support. But __builtin_cpu_support
only works when compiled with clang or gcc. And it requires compiler-rt or
libgcc. I don't know if that's guaranteed to exist on Windows.
Repository:
rL LLVM
https://reviews.llvm.org/D
lebedev.ri added inline comments.
Comment at:
packages/Python/lldbsuite/test/functionalities/register/intel_avx/main.c:21
+ static volatile unsigned haveAVX2;
+ haveAVX2 = __builtin_cpu_supports("avx2");
unsigned int ymmallones = 0x;
Note that you n
aprantl created this revision.
aprantl added reviewers: jasonmolenda, jingham.
Herald added a subscriber: llvm-commits.
I found a cheap and cross-platform way of detecting whether the target supports
AVX2.
Repository:
rL LLVM
https://reviews.llvm.org/D41962
Files:
packages/Python/lldbsui
I can try to take some time to benchmark, hopefully this weekend or so.
I do want to reiterate that this without this change debugging binaries
linked against libstdc++ is badly degraded, since recent libstdc++ uses
ABI tags on ~any methods that touch a std::string.
- Nelson
On Thu, Jan 11, 201
On 11 January 2018 at 16:22, Greg Clayton wrote:
>
>> On Jan 11, 2018, at 8:10 AM, Pavel Labath wrote:
>>
>> On 11 January 2018 at 16:04, Greg Clayton wrote:
>>>
On Jan 11, 2018, at 5:12 AM, Pavel Labath wrote:
Thanks for adding the test Jim. I have confirmed that it passes with
> On Jan 11, 2018, at 8:10 AM, Pavel Labath wrote:
>
> On 11 January 2018 at 16:04, Greg Clayton wrote:
>>
>>> On Jan 11, 2018, at 5:12 AM, Pavel Labath wrote:
>>>
>>> Thanks for adding the test Jim. I have confirmed that it passes with
>>> this patch applied (because the bundle is resolved
On 11 January 2018 at 16:04, Greg Clayton wrote:
>
>> On Jan 11, 2018, at 5:12 AM, Pavel Labath wrote:
>>
>> Thanks for adding the test Jim. I have confirmed that it passes with
>> this patch applied (because the bundle is resolved during target
>> creating, not launching).
>>
>> However, this di
In that case I think Platform should implement all the logic it needs in
itself, instead of relying Host to callback into it.
I think the point of this patch is to separate dependencies, so Platform
should be able to depend on Host, but not vice versa.
On Thu, Jan 11, 2018 at 8:05 AM Greg Clayton
clayborg added a comment.
In https://reviews.llvm.org/D41909#973299, @tberghammer wrote:
> Why do we need to lock the Module mutex in SymbolVendor::FindFunctions? I
> think a better option would be to remove that lock and if it is needed then
> lock it just for the calls where it necessary. The
> On Jan 11, 2018, at 5:12 AM, Pavel Labath wrote:
>
> Thanks for adding the test Jim. I have confirmed that it passes with
> this patch applied (because the bundle is resolved during target
> creating, not launching).
>
> However, this did make me aware of the fact that this patch removed
> th
fjricci added a comment.
> I think a better option would be to remove that lock and if it is needed then
> lock it just for the calls where it necessary. The fact that SymbolVendor
> locks a mutex inside a Module feels like a pretty bad layering violation for
> me what can cause many other dead
On Thu, Jan 11, 2018 at 2:01 AM, Pavel Labath via lldb-commits
wrote:
> On 10 January 2018 at 22:51, Greg Clayton wrote:
>> The right solution seems to be adding some sort of custom GNU ABI tag to the
>> DWARF. I know that won't help with existing binaries, but it sounds too
>> expensive to set
tberghammer added a comment.
I think it isn't an A/B locking issue. The problem is that 2 different thread
(main thread and 1 of the DWARF indexer thread) want to lock the mutex at the
same time.
I have a mixed feeling about this change because introducing any sort of race
condition (even if i
labath updated this revision to Diff 129435.
labath added a comment.
Add back bundle resolution to the mac launcher
https://reviews.llvm.org/D41902
Files:
source/Host/common/MonitoringProcessLauncher.cpp
source/Host/freebsd/Host.cpp
source/Host/macosx/Host.mm
source/Host/netbsd/Host.cpp
Thanks for adding the test Jim. I have confirmed that it passes with
this patch applied (because the bundle is resolved during target
creating, not launching).
However, this did make me aware of the fact that this patch removed
the bundle resolution logic from the launcher itself, so I'm going to
Author: labath
Date: Thu Jan 11 04:57:23 2018
New Revision: 322273
URL: http://llvm.org/viewvc/llvm-project?rev=322273&view=rev
Log:
Remove leftover empty folders
These were created by moving stuff around with git. After committing the move
back to svn, the folders holding the original files rema
Author: labath
Date: Thu Jan 11 04:21:58 2018
New Revision: 322271
URL: http://llvm.org/viewvc/llvm-project?rev=322271&view=rev
Log:
Make the bundle folders in the find-app-in-bundle test non-empty
git will not create empty folders, which makes this test fail if the repo is
checked out with git.
tatyana-krasnukha updated this revision to Diff 129425.
tatyana-krasnukha added a comment.
Fixed comment spacing. Changed the comment slightly (words “I added this class
to…” sound now like I did this, so, replaced it with passive voice).
https://reviews.llvm.org/D41584
Files:
source/Plugins
On 10 January 2018 at 22:51, Greg Clayton wrote:
> The right solution seems to be adding some sort of custom GNU ABI tag to the
> DWARF. I know that won't help with existing binaries, but it sounds too
> expensive to set the ASM name for everything.
>
What makes you think it will be expensive?
33 matches
Mail list logo
