Re: [lldb-dev] LLDB performance drop from 3.9 to 4.0

[Pavel Labath via lldb-dev]

Thank you very much for tracking this down.

+1 for making UniqueCStringMap speak ConstString -- i think it just makes
sense given that it already has "unique" in the name.

ConstString already has a GetStringRef accessor. Also adding a conversion
operator may be a good idea, although it probably won't help in all
situations (you'll still have to write StringRef(X).drop_front() etc. if
you want to do stringref operations on the string)

pl

On 20 April 2017 at 01:46, Zachary Turner  wrote:

> It doesn't entirely defeat the purpose, it's just not *as good* as making
> the interfaces take ConstStrings.  StringRef already has a lot of safety
> and usability improvements over raw char pointers, and those improvements
> don't disappear just because you aren't using ConstString.  Although I
> agree that if you can make it work where the interface only accepts and
> returns ConstStrings, and make conversion from ConstString to StringRef
> more seamless, that would be an even better improvement.
>
> On Wed, Apr 19, 2017 at 5:33 PM Scott Smith 
> wrote:
>
>> If I just assume the pointers are from ConstString, then doesn't that
>> defeat the purpose of making the interface safer?  Why not use an actual
>> ConstString and provide conversion operators from ConstString to
>> StringRef?  Seems we should be able to rely on the type system to get us
>> safety and performance.
>>
>> I'll try putting something together tomorrow.
>>
>> On Wed, Apr 19, 2017 at 4:48 PM, Zachary Turner 
>> wrote:
>>
>>> The change was made to make the interface safer and allow propagation of
>>> StringRef through other layers.  The previous code was already taking a
>>> const char *, and so it was working under the assumption that the const
>>> char* passed in came from a ConstString.  As such, continuing to make that
>>> same assumption seems completely reasonable.
>>>
>>> So perhaps you can just change the operator to compare the pointers, as
>>> was being done before.
>>>
>>> On Wed, Apr 19, 2017 at 4:24 PM Scott Smith 
>>> wrote:
>>>
 It looks like it was this change:

 commit 45fb8d00309586c3f7027f66f9f8a0b56bf1cc4a
 Author: Zachary Turner 
 Date:   Thu Oct 6 21:22:44 2016 +

 Convert UniqueCStringMap to use StringRef.

 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@283494
 91177308-0d34-0410-b5e6-96231b3b80d8


 I'm guessing it's because the old code assumed const string, which
 meant that uniqueness comparisons could be done by simply comparing the
 pointer.  Now it needs to use an actual string comparison routine.  This
 code:

  bool operator<(const Entry &rhs) const { return cstring <
 rhs.cstring; }

 didn't actually change in the revision, but cstring went from 'const
 char *' to 'StringRef'.  If you know for sure that all the StringRefs come
 from ConstString, then it'd be easy enough to change the comparison, but I
 don't know how you guarantee that.

 I assume the change was made to allow proper memory cleanup when the
 symbols are discarded?

 On Thu, Apr 13, 2017 at 5:37 AM, Pavel Labath 
 wrote:

> Bisecting the performance regression would be extremely valuable. If
> you want to do that, it would be very appreciated.
>
> On 12 April 2017 at 20:39, Scott Smith via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> For my app I think it's largely parsing debug symbols tables for
>> shared libraries.  My main performance improvement was to increase the
>> parallelism of parsing that information.
>>
>> Funny, gdb/gold has a similar accelerator table (created when you
>> link with -gdb-index).  I assume lldb doesn't know how to parse it.
>>
>> I'll work on bisecting the change.
>>
>> On Wed, Apr 12, 2017 at 12:26 PM, Jason Molenda 
>> wrote:
>>
>>> I don't know exactly when the 3.9 / 4.0 branches were cut, and what
>>> was done between those two points, but in general we don't expect/want 
>>> to
>>> see performance regressions like that.  I'm more familiar with the perf
>>> characteristics on macos, Linux is different in some important regards, 
>>> so
>>> I can only speak in general terms here.
>>>
>>> In your example, you're measuring three things, assuming you have
>>> debug information for MY_PROGRAM.  The first is "Do the initial read of 
>>> the
>>> main binary and its debug information".  The second is "Find all symbol
>>> names 'main'".  The third is "Scan a newly loaded solib's symbols"
>>> (assuming you don't have debug information from solibs from /usr/lib 
>>> etc).
>>> Technically there's some additional stuff here -- launching the process,
>>> detecting solibs as they're loaded, looking up the symbol context when 
>>> we
>>> hit the breakpoint, backtracing a frame or two, etc, but that stuff is
>>> rarely where you'll s

Re: [lldb-dev] Running check-lldb

[Pavel Labath via lldb-dev]

On 19 April 2017 at 19:15, Scott Smith  wrote:

> A combination of:
> 1. Updating to a known good release according to buildbot
> 2. using Ubuntu 14.04
> 3. compiling release using clang-4.0
>
I'd hope that the compiler used to build lldb does not matter. If you see
any differences due to this factor, please let me know.

4. using the dotest command line that buildbot uses
>
The exact command line the buildbot uses is not important.. The only
important distinction from the check-lldb target is the compiler used. By
default it uses the host compiler used to build lldb. As no-one builds
tests using clang-4.0 it's quite possible that some things may be broken
(or just not properly annotated).


> 5. specifying gcc-4.8 instead of the locally compiled clang
>
> has most of the tests passing, with a handful of unexpected successes:
>
> UNEXPECTED SUCCESS: 
> TestRegisterVariables.RegisterVariableTestCase.test_and_run_command_dwarf
> (lang/c/register_variables/TestRegisterVariables.py)
> UNEXPECTED SUCCESS: 
> TestRegisterVariables.RegisterVariableTestCase.test_and_run_command_dwo
> (lang/c/register_variables/TestRegisterVariables.py)
> UNEXPECTED SUCCESS: 
> TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwarf
> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
> UNEXPECTED SUCCESS: TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwo
> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
> UNEXPECTED SUCCESS: 
> TestThreadStates.ThreadStateTestCase.test_process_interrupt_dwarf
> (functionalities/thread/state/TestThreadStates.py)
> UNEXPECTED SUCCESS: 
> TestThreadStates.ThreadStateTestCase.test_process_interrupt_dwo
> (functionalities/thread/state/TestThreadStates.py)
> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwarf
> (functionalities/signal/raise/TestRaise.py)
> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwo
> (functionalities/signal/raise/TestRaise.py)
> UNEXPECTED SUCCESS: 
> TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwarf
> (api/multithreaded/TestMultithreaded.py)
> UNEXPECTED SUCCESS: 
> TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwo
> (api/multithreaded/TestMultithreaded.py)
> UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwarf
> (lang/cpp/printf/TestPrintf.py)
> UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwo
> (lang/cpp/printf/TestPrintf.py)
>
The unexpected successes are expected, unfortunately. :) What happens here
is that the tests are flaky and they fail like 1% of the time, so they are
marked as xfail.


>
> This looks different than another user's issue: http://lists.llvm.org/
> pipermail/lldb-dev/2016-February/009504.html
>
> I also tried gcc-4.9.4 (via the ubuntu-toolchain-r ppa) and got a
> different set of problems:
>
> FAIL: TestNamespaceDefinitions.NamespaceDefinitionsTestCase.test_expr_dwarf
> (lang/cpp/namespace_definitions/TestNamespaceDefinitions.py)
> FAIL: TestNamespaceDefinitions.NamespaceDefinitionsTestCase.test_expr_dwo
> (lang/cpp/namespace_definitions/TestNamespaceDefinitions.py)
> FAIL: TestTopLevelExprs.TopLevelExpressionsTestCase.
> test_top_level_expressions_dwarf (expression_command/top-level/
> TestTopLevelExprs.py)
> FAIL: 
> TestTopLevelExprs.TopLevelExpressionsTestCase.test_top_level_expressions_dwo
> (expression_command/top-level/TestTopLevelExprs.py)
> UNEXPECTED SUCCESS: 
> TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwarf
> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
> UNEXPECTED SUCCESS: TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwo
> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
> UNEXPECTED SUCCESS: 
> TestThreadStates.ThreadStateTestCase.test_process_interrupt_dwarf
> (functionalities/thread/state/TestThreadStates.py)
> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwarf
> (functionalities/signal/raise/TestRaise.py)
> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwo
> (functionalities/signal/raise/TestRaise.py)
> UNEXPECTED SUCCESS: 
> TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwarf
> (api/multithreaded/TestMultithreaded.py)
> UNEXPECTED SUCCESS: 
> TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwo
> (api/multithreaded/TestMultithreaded.py)
> UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwarf
> (lang/cpp/printf/TestPrintf.py)
> UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwo
> (lang/cpp/printf/TestPrintf.py)
>
> Well, at least the list is consistent, which gives me a base to start
> testing race conditions :-)
>

Interesting, the bot uses a locally-built gcc-4.9.2 and those tests seem to
work there... I'll see if I can find the time to check that out.

Could you please also share the list of failures when using the top-of-tree
clang. I've tried that configuration yesterday on my home machine (x86_64
gento

Re: [lldb-dev] Running check-lldb

[Tamas Berghammer via lldb-dev]

AFAIK the Ubuntu 14.04 cmake builder runs tests using ToT clang (built on
the build bot) as step test3 and test4 and it seems to be green so if you
are seeing different result then I would expect it to be caused by a
configuration difference between the setup the bot has and you have (or the
bot runs the tests incorrectly).

On Thu, Apr 20, 2017 at 2:47 PM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> On 19 April 2017 at 19:15, Scott Smith 
> wrote:
>
>> A combination of:
>> 1. Updating to a known good release according to buildbot
>> 2. using Ubuntu 14.04
>> 3. compiling release using clang-4.0
>>
> I'd hope that the compiler used to build lldb does not matter. If you see
> any differences due to this factor, please let me know.
>
> 4. using the dotest command line that buildbot uses
>>
> The exact command line the buildbot uses is not important.. The only
> important distinction from the check-lldb target is the compiler used. By
> default it uses the host compiler used to build lldb. As no-one builds
> tests using clang-4.0 it's quite possible that some things may be broken
> (or just not properly annotated).
>
>
>> 5. specifying gcc-4.8 instead of the locally compiled clang
>>
>> has most of the tests passing, with a handful of unexpected successes:
>>
>> UNEXPECTED SUCCESS:
>> TestRegisterVariables.RegisterVariableTestCase.test_and_run_command_dwarf
>> (lang/c/register_variables/TestRegisterVariables.py)
>> UNEXPECTED SUCCESS:
>> TestRegisterVariables.RegisterVariableTestCase.test_and_run_command_dwo
>> (lang/c/register_variables/TestRegisterVariables.py)
>> UNEXPECTED SUCCESS:
>> TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwarf
>> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
>> UNEXPECTED SUCCESS:
>> TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwo
>> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
>> UNEXPECTED SUCCESS:
>> TestThreadStates.ThreadStateTestCase.test_process_interrupt_dwarf
>> (functionalities/thread/state/TestThreadStates.py)
>> UNEXPECTED SUCCESS:
>> TestThreadStates.ThreadStateTestCase.test_process_interrupt_dwo
>> (functionalities/thread/state/TestThreadStates.py)
>> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwarf
>> (functionalities/signal/raise/TestRaise.py)
>> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwo
>> (functionalities/signal/raise/TestRaise.py)
>> UNEXPECTED SUCCESS:
>> TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwarf
>> (api/multithreaded/TestMultithreaded.py)
>> UNEXPECTED SUCCESS:
>> TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwo
>> (api/multithreaded/TestMultithreaded.py)
>> UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwarf
>> (lang/cpp/printf/TestPrintf.py)
>> UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwo
>> (lang/cpp/printf/TestPrintf.py)
>>
> The unexpected successes are expected, unfortunately. :) What happens here
> is that the tests are flaky and they fail like 1% of the time, so they are
> marked as xfail.
>
>
>>
>> This looks different than another user's issue:
>> http://lists.llvm.org/pipermail/lldb-dev/2016-February/009504.html
>>
>> I also tried gcc-4.9.4 (via the ubuntu-toolchain-r ppa) and got a
>> different set of problems:
>>
>> FAIL:
>> TestNamespaceDefinitions.NamespaceDefinitionsTestCase.test_expr_dwarf
>> (lang/cpp/namespace_definitions/TestNamespaceDefinitions.py)
>> FAIL: TestNamespaceDefinitions.NamespaceDefinitionsTestCase.test_expr_dwo
>> (lang/cpp/namespace_definitions/TestNamespaceDefinitions.py)
>> FAIL:
>> TestTopLevelExprs.TopLevelExpressionsTestCase.test_top_level_expressions_dwarf
>> (expression_command/top-level/TestTopLevelExprs.py)
>> FAIL:
>> TestTopLevelExprs.TopLevelExpressionsTestCase.test_top_level_expressions_dwo
>> (expression_command/top-level/TestTopLevelExprs.py)
>> UNEXPECTED SUCCESS:
>> TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwarf
>> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
>> UNEXPECTED SUCCESS:
>> TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwo
>> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
>> UNEXPECTED SUCCESS:
>> TestThreadStates.ThreadStateTestCase.test_process_interrupt_dwarf
>> (functionalities/thread/state/TestThreadStates.py)
>> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwarf
>> (functionalities/signal/raise/TestRaise.py)
>> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwo
>> (functionalities/signal/raise/TestRaise.py)
>> UNEXPECTED SUCCESS:
>> TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwarf
>> (api/multithreaded/TestMultithreaded.py)
>> UNEXPECTED SUCCESS:
>> TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwo
>> (api/multithreaded/TestMultithreaded.py)
>> UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwarf
>> (lang/cpp/printf

Re: [lldb-dev] Running check-lldb

[Pavel Labath via lldb-dev]

On 20 April 2017 at 15:01, Tamas Berghammer  wrote:

> AFAIK the Ubuntu 14.04 cmake builder runs tests using ToT clang (built on
> the build bot) as step test3 and test4 and it seems to be green so if you
> are seeing different result then I would expect it to be caused by a
> configuration difference between the setup the bot has and you have (or the
> bot runs the tests incorrectly).
>

Yes, that is my assumption. I'd like to see the tests that are failing (and
how) to see if we can eliminate the system dependencies from these tests...
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB-MI remote debugging on Linux

[Pavel Labath via lldb-dev]

Hi,

this is a known problem and somewhat embarrassing problem, but
unfortunately we haven't had time to look at that yet. The code that is
doing that was added to support loading of the vdso, which is only present
in the application memory (and it is a full elf file). I don't think
anybody has realized the full implications of this when it was being added.
Patches fixing this would be very wellcome.

On 19 April 2017 at 15:17, Scott Funkenhauser via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hey,
>
> I'm exploring using lldb-mi and lldb-server to remotely debug a process
> running on a Linux host.  I'm running into an issue where lldb-mi is
> failing to load the ELF section headers from the remote process's memory
> for certain shared libraries.
>
> Looking at ObjectFileELF:GetSectionHeaderInfo I believe it is trying to
> read the section headers from  header offset>.  As far as I'm aware, on Linux shared libraries aren't
> required to be loaded in a contiguous block of memory, nor are the section
> headers even required to be loaded in memory.
>
> I was wondering if this is a know issue?  If so is there a bug tracking
> the progress?
> Is remote debugging on Linux just not supported yet?  Is this something
> that is being actively worked on?
>
> Thanks,
> Scott
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] lldb crash while single-stepping remote target

[Beverly Trahan via lldb-dev]

Hi, been seeing an issue very frequently while single-stepping a remote 
multithreaded iOS target.  Host is OS X. The crash is in 
ProcessGDBRemote::WillPublicStop, close to NULL.  I downloaded the latest 
source from git and compiled a debug version.  Same scenario crashed in 
assertion in GetItemAtIndex, idx < GetSize().  The issue appears to be a race 
between (ProcessGDBRemote.cpp):

here>  const size_t n = thread_infos->GetSize();
  for (size_t i = 0; i < n; ++i) {
here>StructuredData::Dictionary *thread_dict =
thread_infos->GetItemAtIndex(i)->GetAsDictionary();


For testing, I added:
std::lock_guard guard(m_thread_list_real.GetMutex());

To first line of ProcessGDBRemote::WillPublicStop.  Seemed to resolve my issue, 
but have not tested extensively.

Best regards,

Braden___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB-MI remote debugging on Linux

[Scott Funkenhauser via lldb-dev]

Hey Pavel,

What would be a reasonable solution?

Does having the lldb-server read the shared libraries from disk (instead of
from the process's memory) sound sensible?

Scott

On Thu, Apr 20, 2017 at 10:30 AM, Pavel Labath  wrote:

> Hi,
>
> this is a known problem and somewhat embarrassing problem, but
> unfortunately we haven't had time to look at that yet. The code that is
> doing that was added to support loading of the vdso, which is only present
> in the application memory (and it is a full elf file). I don't think
> anybody has realized the full implications of this when it was being added.
> Patches fixing this would be very wellcome.
>
> On 19 April 2017 at 15:17, Scott Funkenhauser via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hey,
>>
>> I'm exploring using lldb-mi and lldb-server to remotely debug a process
>> running on a Linux host.  I'm running into an issue where lldb-mi is
>> failing to load the ELF section headers from the remote process's memory
>> for certain shared libraries.
>>
>> Looking at ObjectFileELF:GetSectionHeaderInfo I believe it is trying to
>> read the section headers from > header offset>.  As far as I'm aware, on Linux shared libraries aren't
>> required to be loaded in a contiguous block of memory, nor are the section
>> headers even required to be loaded in memory.
>>
>> I was wondering if this is a know issue?  If so is there a bug tracking
>> the progress?
>> Is remote debugging on Linux just not supported yet?  Is this something
>> that is being actively worked on?
>>
>> Thanks,
>> Scott
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB performance drop from 3.9 to 4.0

[Scott Smith via lldb-dev]

What's the preferred way to post changes?  In the past I tried emailing
here but it was pointed out I should send to lldb-commit instead.  But,
there's also phabricator for web-based code reviews.

So,

1. just email lldb-commits?
2. post on http://reviews.llvm.org/?

On Thu, Apr 20, 2017 at 3:16 AM, Pavel Labath  wrote:

> Thank you very much for tracking this down.
>
> +1 for making UniqueCStringMap speak ConstString -- i think it just makes
> sense given that it already has "unique" in the name.
>
> ConstString already has a GetStringRef accessor. Also adding a conversion
> operator may be a good idea, although it probably won't help in all
> situations (you'll still have to write StringRef(X).drop_front() etc. if
> you want to do stringref operations on the string)
>
> pl
>
> On 20 April 2017 at 01:46, Zachary Turner  wrote:
>
>> It doesn't entirely defeat the purpose, it's just not *as good* as making
>> the interfaces take ConstStrings.  StringRef already has a lot of safety
>> and usability improvements over raw char pointers, and those improvements
>> don't disappear just because you aren't using ConstString.  Although I
>> agree that if you can make it work where the interface only accepts and
>> returns ConstStrings, and make conversion from ConstString to StringRef
>> more seamless, that would be an even better improvement.
>>
>> On Wed, Apr 19, 2017 at 5:33 PM Scott Smith 
>> wrote:
>>
>>> If I just assume the pointers are from ConstString, then doesn't that
>>> defeat the purpose of making the interface safer?  Why not use an actual
>>> ConstString and provide conversion operators from ConstString to
>>> StringRef?  Seems we should be able to rely on the type system to get us
>>> safety and performance.
>>>
>>> I'll try putting something together tomorrow.
>>>
>>> On Wed, Apr 19, 2017 at 4:48 PM, Zachary Turner 
>>> wrote:
>>>
 The change was made to make the interface safer and allow propagation
 of StringRef through other layers.  The previous code was already taking a
 const char *, and so it was working under the assumption that the const
 char* passed in came from a ConstString.  As such, continuing to make that
 same assumption seems completely reasonable.

 So perhaps you can just change the operator to compare the pointers, as
 was being done before.

 On Wed, Apr 19, 2017 at 4:24 PM Scott Smith <
 scott.sm...@purestorage.com> wrote:

> It looks like it was this change:
>
> commit 45fb8d00309586c3f7027f66f9f8a0b56bf1cc4a
> Author: Zachary Turner 
> Date:   Thu Oct 6 21:22:44 2016 +
>
> Convert UniqueCStringMap to use StringRef.
>
> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@283494
> 91177308-0d34-0410-b5e6-96231b3b80d8
>
>
> I'm guessing it's because the old code assumed const string, which
> meant that uniqueness comparisons could be done by simply comparing the
> pointer.  Now it needs to use an actual string comparison routine.  This
> code:
>
>  bool operator<(const Entry &rhs) const { return cstring <
> rhs.cstring; }
>
> didn't actually change in the revision, but cstring went from 'const
> char *' to 'StringRef'.  If you know for sure that all the StringRefs come
> from ConstString, then it'd be easy enough to change the comparison, but I
> don't know how you guarantee that.
>
> I assume the change was made to allow proper memory cleanup when the
> symbols are discarded?
>
> On Thu, Apr 13, 2017 at 5:37 AM, Pavel Labath 
> wrote:
>
>> Bisecting the performance regression would be extremely valuable. If
>> you want to do that, it would be very appreciated.
>>
>> On 12 April 2017 at 20:39, Scott Smith via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> For my app I think it's largely parsing debug symbols tables for
>>> shared libraries.  My main performance improvement was to increase the
>>> parallelism of parsing that information.
>>>
>>> Funny, gdb/gold has a similar accelerator table (created when you
>>> link with -gdb-index).  I assume lldb doesn't know how to parse it.
>>>
>>> I'll work on bisecting the change.
>>>
>>> On Wed, Apr 12, 2017 at 12:26 PM, Jason Molenda 
>>> wrote:
>>>
 I don't know exactly when the 3.9 / 4.0 branches were cut, and what
 was done between those two points, but in general we don't expect/want 
 to
 see performance regressions like that.  I'm more familiar with the perf
 characteristics on macos, Linux is different in some important 
 regards, so
 I can only speak in general terms here.

 In your example, you're measuring three things, assuming you have
 debug information for MY_PROGRAM.  The first is "Do the initial read 
 of the
 main binary and its debug information".  The se

Re: [lldb-dev] LLDB performance drop from 3.9 to 4.0

[Zachary Turner via lldb-dev]

#2 is preferred.  When you do it, make sure to add lldb-commits in the
subscribers field.  You're also free to add specific people to the
reviewers field, but the mailing list specifically has to be on
subscribers.  Unfortunately, due to what I assume are bugs in Phabricator,
if you don't get the subscribers right the first time, you have to delete
and re-create the revision.  Adding it as part of an update will not cause
emails to start being sent to the list.

On Thu, Apr 20, 2017 at 11:01 AM Scott Smith 
wrote:

> What's the preferred way to post changes?  In the past I tried emailing
> here but it was pointed out I should send to lldb-commit instead.  But,
> there's also phabricator for web-based code reviews.
>
> So,
>
> 1. just email lldb-commits?
> 2. post on http://reviews.llvm.org/?
>
> On Thu, Apr 20, 2017 at 3:16 AM, Pavel Labath  wrote:
>
>> Thank you very much for tracking this down.
>>
>> +1 for making UniqueCStringMap speak ConstString -- i think it just makes
>> sense given that it already has "unique" in the name.
>>
>> ConstString already has a GetStringRef accessor. Also adding a conversion
>> operator may be a good idea, although it probably won't help in all
>> situations (you'll still have to write StringRef(X).drop_front() etc. if
>> you want to do stringref operations on the string)
>>
>> pl
>>
>> On 20 April 2017 at 01:46, Zachary Turner  wrote:
>>
>>> It doesn't entirely defeat the purpose, it's just not *as good* as
>>> making the interfaces take ConstStrings.  StringRef already has a lot of
>>> safety and usability improvements over raw char pointers, and those
>>> improvements don't disappear just because you aren't using ConstString.
>>> Although I agree that if you can make it work where the interface only
>>> accepts and returns ConstStrings, and make conversion from ConstString to
>>> StringRef more seamless, that would be an even better improvement.
>>>
>>> On Wed, Apr 19, 2017 at 5:33 PM Scott Smith 
>>> wrote:
>>>
 If I just assume the pointers are from ConstString, then doesn't that
 defeat the purpose of making the interface safer?  Why not use an actual
 ConstString and provide conversion operators from ConstString to
 StringRef?  Seems we should be able to rely on the type system to get us
 safety and performance.

 I'll try putting something together tomorrow.

 On Wed, Apr 19, 2017 at 4:48 PM, Zachary Turner 
 wrote:

> The change was made to make the interface safer and allow propagation
> of StringRef through other layers.  The previous code was already taking a
> const char *, and so it was working under the assumption that the const
> char* passed in came from a ConstString.  As such, continuing to make that
> same assumption seems completely reasonable.
>
> So perhaps you can just change the operator to compare the pointers,
> as was being done before.
>
> On Wed, Apr 19, 2017 at 4:24 PM Scott Smith <
> scott.sm...@purestorage.com> wrote:
>
>> It looks like it was this change:
>>
>> commit 45fb8d00309586c3f7027f66f9f8a0b56bf1cc4a
>> Author: Zachary Turner 
>> Date:   Thu Oct 6 21:22:44 2016 +
>>
>> Convert UniqueCStringMap to use StringRef.
>>
>> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@283494
>> 91177308-0d34-0410-b5e6-96231b3b80d8
>>
>>
>> I'm guessing it's because the old code assumed const string, which
>> meant that uniqueness comparisons could be done by simply comparing the
>> pointer.  Now it needs to use an actual string comparison routine.  This
>> code:
>>
>>  bool operator<(const Entry &rhs) const { return cstring <
>> rhs.cstring; }
>>
>> didn't actually change in the revision, but cstring went from 'const
>> char *' to 'StringRef'.  If you know for sure that all the StringRefs 
>> come
>> from ConstString, then it'd be easy enough to change the comparison, but 
>> I
>> don't know how you guarantee that.
>>
>> I assume the change was made to allow proper memory cleanup when the
>> symbols are discarded?
>>
>> On Thu, Apr 13, 2017 at 5:37 AM, Pavel Labath 
>> wrote:
>>
>>> Bisecting the performance regression would be extremely valuable. If
>>> you want to do that, it would be very appreciated.
>>>
>>> On 12 April 2017 at 20:39, Scott Smith via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 For my app I think it's largely parsing debug symbols tables for
 shared libraries.  My main performance improvement was to increase the
 parallelism of parsing that information.

 Funny, gdb/gold has a similar accelerator table (created when you
 link with -gdb-index).  I assume lldb doesn't know how to parse it.

 I'll work on bisecting the change.

 On Wed, Apr 12, 2017 at 12:26 PM, Jason Molenda 
>>>

Re: [lldb-dev] Patch to Attach pid successfully from different dir

[Kamil Rytarowski via lldb-dev]

Thanks, Ed Maste is the current FreeBSD maintainer.

On 20.04.2017 07:36, vignesh balu wrote:
> Created Review : https://reviews.llvm.org/D32271 
> 
> Do i need to assign the reviewers ? if so please let me know how to get
> reviewers list.
> 
> -vbalu
> 
> 
> On Wed, Apr 19, 2017 at 7:59 PM, Kamil Rytarowski  > wrote:
> 
> On 19.04.2017 16:15, vignesh balu via lldb-dev wrote:
> > Hi,
> > Firstly, I am new to the community, So please bear with my
> mistakes and
> > guide me to be on your wavelength.
> >
> > While using lldb we found the small bug with attaching to the running
> > process.
> > "attach" works fine when we run the lldb on the same dir where we ran
> > the executable but not if the dir changes.
> >
> >> cd lldb_temp/
> >> ./test &
> > [2] 39044
> >> cd ../
> >> /b/vignesh/lldb_daily_build/20170419_bkup/binaries/bin/lldb
> > (lldb) attach 39044
> > error: attach failed: unable to find executable for './test'
> >
> > I see the lldb using the relative path instead of absolute path of
> the exe.
> > Modified the way sysctl gets the exe name to get the absolute path.
> >
> > Attached the patch which does the work. I did my testing on Fbsd10.
> > Please let me know how to commit it
> >
> > -regards,
> > vbalu
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org 
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> >
> 
> Please submit your code to https://reviews.llvm.org/
> 
> Please try to use clang-format before submission.
> 
> 




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Running check-lldb

[Scott Smith via lldb-dev]

On Thu, Apr 20, 2017 at 6:47 AM, Pavel Labath  wrote:

> 5. specifying gcc-4.8 instead of the locally compiled clang
>
> has most of the tests passing, with a handful of unexpected successes:
>>
>> UNEXPECTED SUCCESS: TestRegisterVariables.Register
>> VariableTestCase.test_and_run_command_dwarf
>> (lang/c/register_variables/TestRegisterVariables.py)
>> UNEXPECTED SUCCESS: TestRegisterVariables.Register
>> VariableTestCase.test_and_run_command_dwo (lang/c/register_variables/Tes
>> tRegisterVariables.py)
>> UNEXPECTED SUCCESS: 
>> TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwarf
>> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
>> UNEXPECTED SUCCESS: TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwo
>> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
>> UNEXPECTED SUCCESS: TestThreadStates.ThreadStateTe
>> stCase.test_process_interrupt_dwarf (functionalities/thread/state/
>> TestThreadStates.py)
>> UNEXPECTED SUCCESS: TestThreadStates.ThreadStateTe
>> stCase.test_process_interrupt_dwo (functionalities/thread/state/
>> TestThreadStates.py)
>> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwarf
>> (functionalities/signal/raise/TestRaise.py)
>> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwo
>> (functionalities/signal/raise/TestRaise.py)
>> UNEXPECTED SUCCESS: TestMultithreaded.SBBreakpoint
>> CallbackCase.test_sb_api_listener_resume_dwarf
>> (api/multithreaded/TestMultithreaded.py)
>> UNEXPECTED SUCCESS: TestMultithreaded.SBBreakpoint
>> CallbackCase.test_sb_api_listener_resume_dwo
>> (api/multithreaded/TestMultithreaded.py)
>> UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwarf
>> (lang/cpp/printf/TestPrintf.py)
>> UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwo
>> (lang/cpp/printf/TestPrintf.py)
>>
> The unexpected successes are expected, unfortunately. :) What happens here
> is that the tests are flaky and they fail like 1% of the time, so they are
> marked as xfail.
>

Top of tree clang has the same set of unexpected successes.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Running check-lldb

[Scott Smith via lldb-dev]

Sorry, I take that back.  I forgot to save the buffer that ran the test
script.  Oops :-(

I get a number of errors that make me think it's missing libc++, which
makes sense because I never installed it.  However, I thought clang
automatically falls back to using gcc's libstdc++.

Failures include:

Build Command Output:
main.cpp:10:10: fatal error: 'atomic' file not found
#include 
 ^~~~
1 error generated.

and

Build Command Output:
main.cpp:1:10: fatal error: 'string' file not found
#include 
 ^~~~
1 error generated.




On Thu, Apr 20, 2017 at 11:30 AM, Scott Smith 
wrote:

> On Thu, Apr 20, 2017 at 6:47 AM, Pavel Labath  wrote:
>
>> 5. specifying gcc-4.8 instead of the locally compiled clang
>>
>> has most of the tests passing, with a handful of unexpected successes:
>>>
>>> UNEXPECTED SUCCESS: TestRegisterVariables.Register
>>> VariableTestCase.test_and_run_command_dwarf
>>> (lang/c/register_variables/TestRegisterVariables.py)
>>> UNEXPECTED SUCCESS: TestRegisterVariables.Register
>>> VariableTestCase.test_and_run_command_dwo (lang/c/register_variables/Tes
>>> tRegisterVariables.py)
>>> UNEXPECTED SUCCESS: 
>>> TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwarf
>>> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
>>> UNEXPECTED SUCCESS: 
>>> TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwo
>>> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
>>> UNEXPECTED SUCCESS: TestThreadStates.ThreadStateTe
>>> stCase.test_process_interrupt_dwarf (functionalities/thread/state/
>>> TestThreadStates.py)
>>> UNEXPECTED SUCCESS: TestThreadStates.ThreadStateTe
>>> stCase.test_process_interrupt_dwo (functionalities/thread/state/
>>> TestThreadStates.py)
>>> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwarf
>>> (functionalities/signal/raise/TestRaise.py)
>>> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwo
>>> (functionalities/signal/raise/TestRaise.py)
>>> UNEXPECTED SUCCESS: TestMultithreaded.SBBreakpoint
>>> CallbackCase.test_sb_api_listener_resume_dwarf
>>> (api/multithreaded/TestMultithreaded.py)
>>> UNEXPECTED SUCCESS: TestMultithreaded.SBBreakpoint
>>> CallbackCase.test_sb_api_listener_resume_dwo
>>> (api/multithreaded/TestMultithreaded.py)
>>> UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwarf
>>> (lang/cpp/printf/TestPrintf.py)
>>> UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwo
>>> (lang/cpp/printf/TestPrintf.py)
>>>
>> The unexpected successes are expected, unfortunately. :) What happens
>> here is that the tests are flaky and they fail like 1% of the time, so they
>> are marked as xfail.
>>
>
> Top of tree clang has the same set of unexpected successes.
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Running check-lldb

[Pavel Labath via lldb-dev]

On 20 April 2017 at 19:42, Scott Smith  wrote:

> Sorry, I take that back.  I forgot to save the buffer that ran the test
> script.  Oops :-(
>
> I get a number of errors that make me think it's missing libc++, which
> makes sense because I never installed it.  However, I thought clang
> automatically falls back to using gcc's libstdc++.
>
>
It does, however, we have tests which explicitly request libc++ to test the
relevant pretty-printers.

That said, the tests should detect libc++ presence and get skipped if you
don't have it, but that could have gone wrong. Can you send me the exact
list of tests which are failing (and also make sure to sync to master, as I
have fixed a couple of these today).

thanks,
pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev