date:20160929

Re: [Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of

2016-09-29 Thread Dimitar Vlahovski via lldb-commits

Hi,

Is the work that you are currently doing the reason why the lldb build on
i386 is failing?
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/20099

Dimitar


On Thu, Sep 29, 2016 at 5:30 AM, Jason Molenda via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Good suggestions, thanks.  I'll fix those when I commit the 32-bit version
> of the same test.
>
> J
>
> > On Sep 28, 2016, at 9:28 PM, Zachary Turner  wrote:
> >
> >
> >
> > On Wed, Sep 28, 2016 at 9:10 PM Jason Molenda via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> >
> > +  EXPECT_TRUE(regloc.GetOffset() == -8);
> > This should be
> >
> > EXPECT_EQ(-8, regloc.GetOffset());
> >
> > That way if it fails, you'll get a handy error message that says:
> >
> > Expected: -8
> > Actual: -7
> >
> > If you use EXPECT_TRUE, it's not going to tell you the actual value.
> The same goes for many other places in the file.  Note that you're supposed
> to put the expected value *first*.  The test is the same either way
> obviously, but it affects the printing of the above message.
> >
> > +
> > +  // these could be set to IsSame and be valid -- meaning that the
> > +  // register value is the same as the caller's -- but I'd rather
> > +  // they not be mentioned at all.
> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbp, regloc) == false);
> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r15, regloc) == false);
> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r14, regloc) == false);
> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r13, regloc) == false);
> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r12, regloc) == false);
> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbx, regloc) == false);
> > If you're using EXPECT_TRUE and EXPECT_FALSE, I think it's more
> intuitive to not use the comparison operator.  The above is just
> >
> > EXPECT_FALSE(row_sp->GetRegisterInfo(k_rbx, regloc));
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of

2016-09-29 Thread Dimitar Vlahovski via lldb-commits

This is the first build that failed right after your CL:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/20083

On Thu, Sep 29, 2016 at 1:35 PM, Dimitar Vlahovski 
wrote:

> Hi,
>
> Is the work that you are currently doing the reason why the lldb build on
> i386 is failing?
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-
> 14.04-cmake/builds/20099
>
> Dimitar
>
>
> On Thu, Sep 29, 2016 at 5:30 AM, Jason Molenda via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Good suggestions, thanks.  I'll fix those when I commit the 32-bit
>> version of the same test.
>>
>> J
>>
>> > On Sep 28, 2016, at 9:28 PM, Zachary Turner  wrote:
>> >
>> >
>> >
>> > On Wed, Sep 28, 2016 at 9:10 PM Jason Molenda via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>> >
>> > +  EXPECT_TRUE(regloc.GetOffset() == -8);
>> > This should be
>> >
>> > EXPECT_EQ(-8, regloc.GetOffset());
>> >
>> > That way if it fails, you'll get a handy error message that says:
>> >
>> > Expected: -8
>> > Actual: -7
>> >
>> > If you use EXPECT_TRUE, it's not going to tell you the actual value.
>> The same goes for many other places in the file.  Note that you're supposed
>> to put the expected value *first*.  The test is the same either way
>> obviously, but it affects the printing of the above message.
>> >
>> > +
>> > +  // these could be set to IsSame and be valid -- meaning that the
>> > +  // register value is the same as the caller's -- but I'd rather
>> > +  // they not be mentioned at all.
>> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbp, regloc) == false);
>> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r15, regloc) == false);
>> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r14, regloc) == false);
>> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r13, regloc) == false);
>> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r12, regloc) == false);
>> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbx, regloc) == false);
>> > If you're using EXPECT_TRUE and EXPECT_FALSE, I think it's more
>> intuitive to not use the comparison operator.  The above is just
>> >
>> > EXPECT_FALSE(row_sp->GetRegisterInfo(k_rbx, regloc));
>>
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of

2016-09-29 Thread Pavel Labath via lldb-commits

Note that the test fails when using gcc as a compiler (specifically gcc-4.9
in this case, but hopefully the exact version does not matter here).

Jason, will you be able to check this out today?

On 29 September 2016 at 05:45, Dimitar Vlahovski via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> This is the first build that failed right after your CL:
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-
> 14.04-cmake/builds/20083
>
> On Thu, Sep 29, 2016 at 1:35 PM, Dimitar Vlahovski 
> wrote:
>
>> Hi,
>>
>> Is the work that you are currently doing the reason why the lldb build on
>> i386 is failing?
>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake
>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-
>> cmake/builds/20099
>>
>> Dimitar
>>
>>
>> On Thu, Sep 29, 2016 at 5:30 AM, Jason Molenda via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> Good suggestions, thanks.  I'll fix those when I commit the 32-bit
>>> version of the same test.
>>>
>>> J
>>>
>>> > On Sep 28, 2016, at 9:28 PM, Zachary Turner 
>>> wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Sep 28, 2016 at 9:10 PM Jason Molenda via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>> >
>>> > +  EXPECT_TRUE(regloc.GetOffset() == -8);
>>> > This should be
>>> >
>>> > EXPECT_EQ(-8, regloc.GetOffset());
>>> >
>>> > That way if it fails, you'll get a handy error message that says:
>>> >
>>> > Expected: -8
>>> > Actual: -7
>>> >
>>> > If you use EXPECT_TRUE, it's not going to tell you the actual value.
>>> The same goes for many other places in the file.  Note that you're supposed
>>> to put the expected value *first*.  The test is the same either way
>>> obviously, but it affects the printing of the above message.
>>> >
>>> > +
>>> > +  // these could be set to IsSame and be valid -- meaning that the
>>> > +  // register value is the same as the caller's -- but I'd rather
>>> > +  // they not be mentioned at all.
>>> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbp, regloc) == false);
>>> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r15, regloc) == false);
>>> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r14, regloc) == false);
>>> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r13, regloc) == false);
>>> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r12, regloc) == false);
>>> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbx, regloc) == false);
>>> > If you're using EXPECT_TRUE and EXPECT_FALSE, I think it's more
>>> intuitive to not use the comparison operator.  The above is just
>>> >
>>> > EXPECT_FALSE(row_sp->GetRegisterInfo(k_rbx, regloc));
>>>
>>> ___
>>> lldb-commits mailing list
>>> lldb-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>>
>>
>>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D25057: Fix ARM/AArch64 Step-Over watchpoint issue remove provision for duplicate watchpoints

2016-09-29 Thread Pavel Labath via lldb-commits

[phabricator seems to be down, so I'll reply here]

Thank you for looking into this.

Hmm... I think we can consider this an improvement over the status quo, but
it's not going to solve the problem in all cases. E.g., on aarch64, a
single stp instruction with neon registers can access a block of memory of
size 32 (on arm a similar thing can be achieved with a push instruction
with a large set of registers, and I believe there are some cache
management instructions that can access even larger blocks of memory),
which can trigger watchpoints in multiple slots even if they are watching
different regions of memory. This patch will not handle that (in fact, the
problem cannot be fully solved from within nativeregistercontext classes).

The way I was considering handling this is to change the client's behavior
when stepping over the watchpoint -- instead of just disabling the
watchpoint that got reported as hit, we would disable all watchpoints and
re-enable them after the step is complete. This would handle all cases and
you would still be able to set two watchpoints on the same memory region if
you wanted to. The only downside I see there is that we would not be able
to report the fact that multiple watchpoints got triggered, but we don't
have that ability now anyway, and if we really wanted to, we could later
change that code to do some kind of a loop disabling watchpoints one by one
(but I think that's going to happen soon).

So, if you really want to do it this way, I think we can make that happen,
but I would encourage you to try the holistic approach first.

Greg, how this idea sound to you ?

On 28 September 2016 at 17:26, Muhammad Omair Javaid <
omair.jav...@linaro.org> wrote:

> omjavaid created this revision.
> omjavaid added a reviewer: labath.
> omjavaid added a subscriber: lldb-commits.
> Herald added subscribers: samparker, srhines, danalbert, tberghammer,
> rengolin, aemerson.
>
> On ARM Linux targets  watchpoints are reported by PTrace before the
> instruction causing watchpoint to trigger is executed.
> This means we cannot step-over watchpoint causing instruction as long as
> there is watchpoint installed on that location.
> For this reason we cannot have multiple watchpoint slots watching same
> region word/byte/halfword etc as we have to disable watchpoint for stepping
> over and only watchpoint index reported by lldb-server is disabled.
> Similarly we cannot keep a single hardware watchpoint slot referring to
> multiple watchpoints in LLDB. This actually means that hware watchpoint
> indexes are exclusively assigned to a watchpoint and cannot be shared by
> other watchpoint. Also no other watchpoint should watch same address
> already watched by any other index.
>
> More discussion on this can be found here:
> https://reviews.llvm.org/D24610
>
> This patch fixes issue with stepping over watchpoint by removing the
> provision to enable multiple watchpoints referring to same hardware
> watchpoint slot (same HW index). Also we restrict one watchpoint per word
> aligned address so duplication of address will not be allowed to avoid any
> step-over failures.
>
> I have also attached a test-case that tests this scenario.
>
> https://reviews.llvm.org/D25057
>
> Files:
>   packages/Python/lldbsuite/test/functionalities/watchpoint/
> multi_watchpoint_slots/Makefile
>   packages/Python/lldbsuite/test/functionalities/watchpoint/
> multi_watchpoint_slots/TestWatchpointMultipleSlots.py
>   packages/Python/lldbsuite/test/functionalities/watchpoint/
> multi_watchpoint_slots/main.c
>   source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
>   source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r282648 - Fix an issue where libc++ changed the type information we get for std::map::iterator, rendering LLDB unable to display elements vended by an iterator

2016-09-29 Thread Enrico Granata via lldb-commits


> On Sep 28, 2016, at 5:58 PM, Zachary Turner  wrote:
> 
> 
> 
> On Wed, Sep 28, 2016 at 4:02 PM Enrico Granata via lldb-commits 
> mailto:lldb-commits@lists.llvm.org>> wrote:
> 
> -
> +
> +  static ConstString g___i_("__i_");
> +
>// this must be a ValueObject* because it is a child of the ValueObject we 
> are
>// producing children for
>// it if were a ValueObjectSP, we would end up with a loop (iterator ->
> @@ -281,6 +287,57 @@ bool lldb_private::formatters::LibCxxMap
> SyntheticChildrenTraversal::None),
> nullptr)
> .get();
> +
> +  if (!m_pair_ptr) {
> +m_pair_ptr = valobj_sp->GetValueForExpressionPath(".__i_.__ptr_", 
> nullptr, nullptr, nullptr,
> +  
> ValueObject::GetValueForExpressionPathOptions()
> +  
> .DontCheckDotVsArrowSyntax()
> +  
> .SetSyntheticChildrenTraversal(
> + 
> ValueObject::GetValueForExpressionPathOptions::
> + 
> SyntheticChildrenTraversal::None),
> +  nullptr)
> +.get();
> +if (m_pair_ptr) {
> +  auto __i_(valobj_sp->GetChildMemberWithName(g___i_, true));
> Is there any reason we need to use such weird variable names?  This looks 
> like undefined behavior to me.  Variables with more than one adjacent 
> underscore are reserved.

I am naming the variable the same as the corresponding variable in the type I 
am formatting. Future me is usually thankful when I do that.. it helps keep 
track of what ValueObject matches what child element; in this case, our 
iterators have an __i_ child

>  
> +  lldb::TemplateArgumentKind kind;
> +  if (!__i_) {
> +m_pair_ptr = nullptr;
> +return false;
> +  }
> +  CompilerType pair_type(__i_->GetCompilerType().GetTemplateArgument(0, 
> kind));
> +  std::string name; uint64_t bit_offset_ptr; uint32_t 
> bitfield_bit_size_ptr; bool is_bitfield_ptr;
> +  pair_type = pair_type.GetFieldAtIndex(0, name, &bit_offset_ptr, 
> &bitfield_bit_size_ptr, &is_bitfield_ptr);
> +  if (!pair_type) {
> +m_pair_ptr = nullptr;
> +return false;
> +  }
> +
> +  auto addr(m_pair_ptr->GetValueAsUnsigned(LLDB_INVALID_ADDRESS));
> +  m_pair_ptr = nullptr;
> +  if (addr && addr!=LLDB_INVALID_ADDRESS) {
> Can you do an early return here?

Like instead of if (foo) { stuff }
if (!foo) return;
stuff

Sure. It didn't seem that deeply nested to be worth it, but I see no reason why 
I couldn't..

>  
> +ClangASTContext *ast_ctx = 
> llvm::dyn_cast_or_null(pair_type.GetTypeSystem());
> +if (!ast_ctx)
> +  return false;
> +CompilerType tree_node_type = 
> ast_ctx->CreateStructForIdentifier(ConstString(), {
> +  
> {"ptr0",ast_ctx->GetBasicType(lldb::eBasicTypeVoid).GetPointerType()},
> +  
> {"ptr1",ast_ctx->GetBasicType(lldb::eBasicTypeVoid).GetPointerType()},
> +  
> {"ptr2",ast_ctx->GetBasicType(lldb::eBasicTypeVoid).GetPointerType()},
> +  {"cw",ast_ctx->GetBasicType(lldb::eBasicTypeBool)},
> +  {"payload",pair_type}
> +});
> +DataBufferSP buffer_sp(new 
> DataBufferHeap(tree_node_type.GetByteSize(nullptr),0));
> +ProcessSP process_sp(target_sp->GetProcessSP());
> +Error error;
> +process_sp->ReadMemory(addr, buffer_sp->GetBytes(), 
> buffer_sp->GetByteSize(), error);
> +if (error.Fail())
> +  return false;
> +DataExtractor extractor(buffer_sp, process_sp->GetByteOrder(), 
> process_sp->GetAddressByteSize());
> +auto pair_sp = CreateValueObjectFromData("pair", extractor, 
> valobj_sp->GetExecutionContextRef(), tree_node_type);
> +if (pair_sp)
> +  m_pair_sp = pair_sp->GetChildAtIndex(4,true);
> +  }
> +}
> +  }
> 
>return false;
>  }
> @@ -293,9 +350,11 @@ size_t lldb_private::formatters::LibCxxM
>  lldb::ValueObjectSP
>  
> lldb_private::formatters::LibCxxMapIteratorSyntheticFrontEnd::GetChildAtIndex(
>  size_t idx) {
> -  if (!m_pair_ptr)
> -return lldb::ValueObjectSP();
> -  return m_pair_ptr->GetChildAtIndex(idx, true);
> +  if (m_pair_ptr)
> +return m_pair_ptr->GetChildAtIndex(idx, true);
> +  if (m_pair_sp)
> +return m_pair_sp->GetChildAtIndex(idx, true);
> +  return lldb::ValueObjectSP();
>  }
> 
>  bool lldb_private::formatters::LibCxxMapIteratorSyntheticFrontEnd::
> 
> Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxx.h
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxx.h?rev=282648&r1=282647&r2=282648&view=diff
>  
>

Re: [Lldb-commits] [lldb] r282648 - Fix an issue where libc++ changed the type information we get for std::map::iterator, rendering LLDB unable to display elements vended by an iterator

2016-09-29 Thread Zachary Turner via lldb-commits

On Thu, Sep 29, 2016 at 10:43 AM Enrico Granata  wrote:

> On Sep 28, 2016, at 5:58 PM, Zachary Turner  wrote:
>
>
>
> On Wed, Sep 28, 2016 at 4:02 PM Enrico Granata via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>
> -
> +
> +  static ConstString g___i_("__i_");
> +
>// this must be a ValueObject* because it is a child of the ValueObject
> we are
>// producing children for
>// it if were a ValueObjectSP, we would end up with a loop (iterator ->
> @@ -281,6 +287,57 @@ bool lldb_private::formatters::LibCxxMap
> SyntheticChildrenTraversal::None),
> nullptr)
> .get();
> +
> +  if (!m_pair_ptr) {
> +m_pair_ptr = valobj_sp->GetValueForExpressionPath(".__i_.__ptr_",
> nullptr, nullptr, nullptr,
> +
> ValueObject::GetValueForExpressionPathOptions()
> +
> .DontCheckDotVsArrowSyntax()
> +
> .SetSyntheticChildrenTraversal(
> +
>ValueObject::GetValueForExpressionPathOptions::
> +
>SyntheticChildrenTraversal::None),
> +  nullptr)
> +.get();
> +if (m_pair_ptr) {
> +  auto __i_(valobj_sp->GetChildMemberWithName(g___i_, true));
>
> Is there any reason we need to use such weird variable names?  This looks
> like undefined behavior to me.  Variables with more than one adjacent
> underscore are reserved.
>
>
> I am naming the variable the same as the corresponding variable in the
> type I am formatting. Future me is usually thankful when I do that.. it
> helps keep track of what ValueObject matches what child element; in this
> case, our iterators have an __i_ child
>

Ahh, makes sense.  Unfortunately at least in this case it leads to illegal
variable names.  Is there anything else it could be named that would be
similar enough to help remembering but a valid c++ identifier?
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r282648 - Fix an issue where libc++ changed the type information we get for std::map::iterator, rendering LLDB unable to display elements vended by an iterator

2016-09-29 Thread Enrico Granata via lldb-commits


> On Sep 29, 2016, at 10:50 AM, Zachary Turner  wrote:
> 
> 
> 
> On Thu, Sep 29, 2016 at 10:43 AM Enrico Granata  > wrote:
>> On Sep 28, 2016, at 5:58 PM, Zachary Turner > > wrote:
>> 
>> 
>> 
>> On Wed, Sep 28, 2016 at 4:02 PM Enrico Granata via lldb-commits 
>> mailto:lldb-commits@lists.llvm.org>> wrote:
>> 
>> -
>> +
>> +  static ConstString g___i_("__i_");
>> +
>>// this must be a ValueObject* because it is a child of the ValueObject 
>> we are
>>// producing children for
>>// it if were a ValueObjectSP, we would end up with a loop (iterator ->
>> @@ -281,6 +287,57 @@ bool lldb_private::formatters::LibCxxMap
>> SyntheticChildrenTraversal::None),
>> nullptr)
>> .get();
>> +
>> +  if (!m_pair_ptr) {
>> +m_pair_ptr = valobj_sp->GetValueForExpressionPath(".__i_.__ptr_", 
>> nullptr, nullptr, nullptr,
>> +  
>> ValueObject::GetValueForExpressionPathOptions()
>> +  
>> .DontCheckDotVsArrowSyntax()
>> +  
>> .SetSyntheticChildrenTraversal(
>> +
>>  ValueObject::GetValueForExpressionPathOptions::
>> +
>>  SyntheticChildrenTraversal::None),
>> +  nullptr)
>> +.get();
>> +if (m_pair_ptr) {
>> +  auto __i_(valobj_sp->GetChildMemberWithName(g___i_, true));
>> Is there any reason we need to use such weird variable names?  This looks 
>> like undefined behavior to me.  Variables with more than one adjacent 
>> underscore are reserved.
> 
> I am naming the variable the same as the corresponding variable in the type I 
> am formatting. Future me is usually thankful when I do that.. it helps keep 
> track of what ValueObject matches what child element; in this case, our 
> iterators have an __i_ child
> 
> Ahh, makes sense.  Unfortunately at least in this case it leads to illegal 
> variable names.  Is there anything else it could be named that would be 
> similar enough to help remembering but a valid c++ identifier?

Sure, we just add a "vo" prefix, like vo__i_

I thought the rule about __ being magic only applied to global identifiers, and 
I have never seen any compiler complain about those identifiers in practice. 
But reserved is reserved, so thanks for pointing that out.

Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

Re: [Lldb-commits] [lldb] r282648 - Fix an issue where libc++ changed the type information we get for std::map::iterator, rendering LLDB unable to display elements vended by an iterator

2016-09-29 Thread Enrico Granata via lldb-commits


> On Sep 29, 2016, at 10:58 AM, Enrico Granata via lldb-commits 
>  wrote:
> 
> 
>> On Sep 29, 2016, at 10:50 AM, Zachary Turner > > wrote:
>> 
>> 
>> 
>> On Thu, Sep 29, 2016 at 10:43 AM Enrico Granata > > wrote:
>>> On Sep 28, 2016, at 5:58 PM, Zachary Turner >> > wrote:
>>> 
>>> 
>>> 
>>> On Wed, Sep 28, 2016 at 4:02 PM Enrico Granata via lldb-commits 
>>> mailto:lldb-commits@lists.llvm.org>> wrote:
>>> 
>>> -
>>> +
>>> +  static ConstString g___i_("__i_");
>>> +
>>>// this must be a ValueObject* because it is a child of the ValueObject 
>>> we are
>>>// producing children for
>>>// it if were a ValueObjectSP, we would end up with a loop (iterator ->
>>> @@ -281,6 +287,57 @@ bool lldb_private::formatters::LibCxxMap
>>> SyntheticChildrenTraversal::None),
>>> nullptr)
>>> .get();
>>> +
>>> +  if (!m_pair_ptr) {
>>> +m_pair_ptr = valobj_sp->GetValueForExpressionPath(".__i_.__ptr_", 
>>> nullptr, nullptr, nullptr,
>>> +  
>>> ValueObject::GetValueForExpressionPathOptions()
>>> +  
>>> .DontCheckDotVsArrowSyntax()
>>> +  
>>> .SetSyntheticChildrenTraversal(
>>> +   
>>>   ValueObject::GetValueForExpressionPathOptions::
>>> +   
>>>   SyntheticChildrenTraversal::None),
>>> +  nullptr)
>>> +.get();
>>> +if (m_pair_ptr) {
>>> +  auto __i_(valobj_sp->GetChildMemberWithName(g___i_, true));
>>> Is there any reason we need to use such weird variable names?  This looks 
>>> like undefined behavior to me.  Variables with more than one adjacent 
>>> underscore are reserved.
>> 
>> I am naming the variable the same as the corresponding variable in the type 
>> I am formatting. Future me is usually thankful when I do that.. it helps 
>> keep track of what ValueObject matches what child element; in this case, our 
>> iterators have an __i_ child
>> 
>> Ahh, makes sense.  Unfortunately at least in this case it leads to illegal 
>> variable names.  Is there anything else it could be named that would be 
>> similar enough to help remembering but a valid c++ identifier?
> 
> Sure, we just add a "vo" prefix, like vo__i_

And apparently that would also not suffice, double underscores are forbidden 
*anywhere* in an identifier.. Sigh

Let me think about this a little bit.. I'll come up with some rule

> 
> I thought the rule about __ being magic only applied to global identifiers, 
> and I have never seen any compiler complain about those identifiers in 
> practice. But reserved is reserved, so thanks for pointing that out.
> 
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

Re: [Lldb-commits] [lldb] r282648 - Fix an issue where libc++ changed the type information we get for std::map::iterator, rendering LLDB unable to display elements vended by an iterator

2016-09-29 Thread Zachary Turner via lldb-commits

Yea :(  In practice you're right that it might not ever be an issue, but I
know one time I spent quite a long time trying to figure out why I couldn't
create a variable named "unix", so any time I see questionable names it
brings back terrible memories.

On Thu, Sep 29, 2016 at 10:58 AM Enrico Granata  wrote:

>
> On Sep 29, 2016, at 10:50 AM, Zachary Turner  wrote:
>
>
>
> On Thu, Sep 29, 2016 at 10:43 AM Enrico Granata 
> wrote:
>
> On Sep 28, 2016, at 5:58 PM, Zachary Turner  wrote:
>
>
>
> On Wed, Sep 28, 2016 at 4:02 PM Enrico Granata via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>
> -
> +
> +  static ConstString g___i_("__i_");
> +
>// this must be a ValueObject* because it is a child of the ValueObject
> we are
>// producing children for
>// it if were a ValueObjectSP, we would end up with a loop (iterator ->
> @@ -281,6 +287,57 @@ bool lldb_private::formatters::LibCxxMap
> SyntheticChildrenTraversal::None),
> nullptr)
> .get();
> +
> +  if (!m_pair_ptr) {
> +m_pair_ptr = valobj_sp->GetValueForExpressionPath(".__i_.__ptr_",
> nullptr, nullptr, nullptr,
> +
> ValueObject::GetValueForExpressionPathOptions()
> +
> .DontCheckDotVsArrowSyntax()
> +
> .SetSyntheticChildrenTraversal(
> +
>ValueObject::GetValueForExpressionPathOptions::
> +
>SyntheticChildrenTraversal::None),
> +  nullptr)
> +.get();
> +if (m_pair_ptr) {
> +  auto __i_(valobj_sp->GetChildMemberWithName(g___i_, true));
>
> Is there any reason we need to use such weird variable names?  This looks
> like undefined behavior to me.  Variables with more than one adjacent
> underscore are reserved.
>
>
> I am naming the variable the same as the corresponding variable in the
> type I am formatting. Future me is usually thankful when I do that.. it
> helps keep track of what ValueObject matches what child element; in this
> case, our iterators have an __i_ child
>
>
> Ahh, makes sense.  Unfortunately at least in this case it leads to illegal
> variable names.  Is there anything else it could be named that would be
> similar enough to help remembering but a valid c++ identifier?
>
>
> Sure, we just add a "vo" prefix, like vo__i_
>
> I thought the rule about __ being magic only applied to global
> identifiers, and I have never seen any compiler complain about those
> identifiers in practice. But reserved is reserved, so thanks for pointing
> that out.
>
> Thanks,
> *- Enrico*
> 📩 egranata@.com ☎️ 27683
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r282741 - To fix TestObjCMethods2/i386, allowed messaging nil ObjC objects as in x86_64.

2016-09-29 Thread Sean Callanan via lldb-commits

Author: spyffe
Date: Thu Sep 29 12:57:33 2016
New Revision: 282741

URL: http://llvm.org/viewvc/llvm-project?rev=282741&view=rev
Log:
To fix TestObjCMethods2/i386, allowed messaging nil ObjC objects as in x86_64.

Modified:

lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.cpp

Modified: 
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.cpp?rev=282741&r1=282740&r2=282741&view=diff
==
--- 
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.cpp
 Thu Sep 29 12:57:33 2016
@@ -162,6 +162,9 @@ UtilityFunction *AppleObjCRuntimeV1::Cre
   "   \n"
   "   struct __objc_object *obj = (struct "
   "__objc_object*)$__lldb_arg_obj; \n"
+  "   if ($__lldb_arg_obj == (void *)0) "
+  "\n"
+  "   return; // nil is ok  "
   "   (int)strlen(obj->isa->name); 
"
   "   \n"
   "}   
"


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

Re: [Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of

2016-09-29 Thread Jason Molenda via lldb-commits

Yep, will do.  I saw that build bot result last night and ran the testsuite on 
my local ubuntu box and didn't repo the failure so I thought maybe it was an 
already-failing test case that the bot was just telling me about.  But I think 
I was running the test x86_64 - I'll figure out how to run it i386 and look 
into it.

> On Sep 29, 2016, at 5:56 AM, Pavel Labath  wrote:
> 
> Note that the test fails when using gcc as a compiler (specifically gcc-4.9 
> in this case, but hopefully the exact version does not matter here).
> 
> Jason, will you be able to check this out today?
> 
> On 29 September 2016 at 05:45, Dimitar Vlahovski via lldb-commits 
>  wrote:
> This is the first build that failed right after your CL: 
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/20083
> 
> On Thu, Sep 29, 2016 at 1:35 PM, Dimitar Vlahovski  
> wrote:
> Hi,
> 
> Is the work that you are currently doing the reason why the lldb build on 
> i386 is failing?
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/20099
> 
> Dimitar
> 
> 
> On Thu, Sep 29, 2016 at 5:30 AM, Jason Molenda via lldb-commits 
>  wrote:
> Good suggestions, thanks.  I'll fix those when I commit the 32-bit version of 
> the same test.
> 
> J
> 
> > On Sep 28, 2016, at 9:28 PM, Zachary Turner  wrote:
> >
> >
> >
> > On Wed, Sep 28, 2016 at 9:10 PM Jason Molenda via lldb-commits 
> >  wrote:
> >
> > +  EXPECT_TRUE(regloc.GetOffset() == -8);
> > This should be
> >
> > EXPECT_EQ(-8, regloc.GetOffset());
> >
> > That way if it fails, you'll get a handy error message that says:
> >
> > Expected: -8
> > Actual: -7
> >
> > If you use EXPECT_TRUE, it's not going to tell you the actual value.  The 
> > same goes for many other places in the file.  Note that you're supposed to 
> > put the expected value *first*.  The test is the same either way obviously, 
> > but it affects the printing of the above message.
> >
> > +
> > +  // these could be set to IsSame and be valid -- meaning that the
> > +  // register value is the same as the caller's -- but I'd rather
> > +  // they not be mentioned at all.
> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbp, regloc) == false);
> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r15, regloc) == false);
> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r14, regloc) == false);
> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r13, regloc) == false);
> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r12, regloc) == false);
> > +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbx, regloc) == false);
> > If you're using EXPECT_TRUE and EXPECT_FALSE, I think it's more intuitive 
> > to not use the comparison operator.  The above is just
> >
> > EXPECT_FALSE(row_sp->GetRegisterInfo(k_rbx, regloc));
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> 
> 

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

[Lldb-commits] [lldb] r282754 - Fix an issue where, in i386 mode, the wrong values were being copied into the pair object for a single-entry NSDictionary

2016-09-29 Thread Enrico Granata via lldb-commits

Author: enrico
Date: Thu Sep 29 14:46:48 2016
New Revision: 282754

URL: http://llvm.org/viewvc/llvm-project?rev=282754&view=rev
Log:
Fix an issue where, in i386 mode, the wrong values were being copied into the 
pair object for a single-entry NSDictionary

Fixes rdar://28502335


Modified:
lldb/trunk/source/Plugins/Language/ObjC/NSDictionary.cpp

Modified: lldb/trunk/source/Plugins/Language/ObjC/NSDictionary.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/ObjC/NSDictionary.cpp?rev=282754&r1=282753&r2=282754&view=diff
==
--- lldb/trunk/source/Plugins/Language/ObjC/NSDictionary.cpp (original)
+++ lldb/trunk/source/Plugins/Language/ObjC/NSDictionary.cpp Thu Sep 29 
14:46:48 2016
@@ -573,8 +573,8 @@ lldb_private::formatters::NSDictionary1S
 *(data_ptr + 1) = value_at_idx;
   } else {
 uint32_t *data_ptr = (uint32_t *)buffer_sp->GetBytes();
-*data_ptr = key_ptr;
-*(data_ptr + 1) = value_ptr;
+*data_ptr = key_at_idx;
+*(data_ptr + 1) = value_at_idx;
   }
 
   DataExtractor data(buffer_sp, process_sp->GetByteOrder(), ptr_size);


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

Re: [Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of

2016-09-29 Thread Jason Molenda via lldb-commits

Interesting, I can't get the failure to repo with i386 + gcc-4.8 on an ubuntu 
14.04.5 system.  Downloading & building gcc-4.9.4 right now.



$ ./dotest.py -C gcc-4.8 -A i386 --executable ~/build/bin/lldb 
testcases/python_api/sbdata
LLDB library dir: /home/jmolenda/build/bin
LLDB import library dir: /home/jmolenda/build/bin
lldb version 4.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision 282753 
clang revision 282567 llvm revision 282567)
The 'lldb-mi' executable cannot be located.  The lldb-mi tests can not be run 
as a result.

Session logs for test failures/errors/unexpected successes will go into 
directory '2016-09-29-15_09_05'
Command invoked: ./dotest.py -C gcc-4.8 -A i386 --executable 
/home/jmolenda/build/bin/lldb testcases/python_api/sbdata
compilers=['gcc-4.8']

Configuration: arch=i386 compiler=gcc-4.8
--
Collected 2 tests

--
Ran 2 tests in 1.540s

RESULT: PASSED (2 passes, 0 failures, 0 errors, 0 skipped, 0 expected failures, 
0 unexpected successes)


J

> On Sep 29, 2016, at 12:29 PM, Jason Molenda  wrote:
> 
> Yep, will do.  I saw that build bot result last night and ran the testsuite 
> on my local ubuntu box and didn't repo the failure so I thought maybe it was 
> an already-failing test case that the bot was just telling me about.  But I 
> think I was running the test x86_64 - I'll figure out how to run it i386 and 
> look into it.
> 
>> On Sep 29, 2016, at 5:56 AM, Pavel Labath  wrote:
>> 
>> Note that the test fails when using gcc as a compiler (specifically gcc-4.9 
>> in this case, but hopefully the exact version does not matter here).
>> 
>> Jason, will you be able to check this out today?
>> 
>> On 29 September 2016 at 05:45, Dimitar Vlahovski via lldb-commits 
>>  wrote:
>> This is the first build that failed right after your CL: 
>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/20083
>> 
>> On Thu, Sep 29, 2016 at 1:35 PM, Dimitar Vlahovski  
>> wrote:
>> Hi,
>> 
>> Is the work that you are currently doing the reason why the lldb build on 
>> i386 is failing?
>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake
>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/20099
>> 
>> Dimitar
>> 
>> 
>> On Thu, Sep 29, 2016 at 5:30 AM, Jason Molenda via lldb-commits 
>>  wrote:
>> Good suggestions, thanks.  I'll fix those when I commit the 32-bit version 
>> of the same test.
>> 
>> J
>> 
>>> On Sep 28, 2016, at 9:28 PM, Zachary Turner  wrote:
>>> 
>>> 
>>> 
>>> On Wed, Sep 28, 2016 at 9:10 PM Jason Molenda via lldb-commits 
>>>  wrote:
>>> 
>>> +  EXPECT_TRUE(regloc.GetOffset() == -8);
>>> This should be
>>> 
>>> EXPECT_EQ(-8, regloc.GetOffset());
>>> 
>>> That way if it fails, you'll get a handy error message that says:
>>> 
>>> Expected: -8
>>> Actual: -7
>>> 
>>> If you use EXPECT_TRUE, it's not going to tell you the actual value.  The 
>>> same goes for many other places in the file.  Note that you're supposed to 
>>> put the expected value *first*.  The test is the same either way obviously, 
>>> but it affects the printing of the above message.
>>> 
>>> +
>>> +  // these could be set to IsSame and be valid -- meaning that the
>>> +  // register value is the same as the caller's -- but I'd rather
>>> +  // they not be mentioned at all.
>>> +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbp, regloc) == false);
>>> +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r15, regloc) == false);
>>> +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r14, regloc) == false);
>>> +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r13, regloc) == false);
>>> +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_r12, regloc) == false);
>>> +  EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbx, regloc) == false);
>>> If you're using EXPECT_TRUE and EXPECT_FALSE, I think it's more intuitive 
>>> to not use the comparison operator.  The above is just
>>> 
>>> EXPECT_FALSE(row_sp->GetRegisterInfo(k_rbx, regloc));
>> 
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>> 
>> 
>> 
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>> 
>> 
> 

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

[Lldb-commits] [lldb] r282774 - This test will not work in i386 mode because we don't create interesting types from the ObjC runtime

2016-09-29 Thread Enrico Granata via lldb-commits

Author: enrico
Date: Thu Sep 29 16:20:56 2016
New Revision: 282774

URL: http://llvm.org/viewvc/llvm-project?rev=282774&view=rev
Log:
This test will not work in i386 mode because we don't create interesting types 
from the ObjC runtime

"Fixes" rdar://28501616


Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py?rev=282774&r1=282773&r2=282774&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py
 Thu Sep 29 16:20:56 2016
@@ -25,6 +25,7 @@ class TypeLookupTestCase(TestBase):
 self.line = line_number('main.m', '// break here')
 
 @skipUnlessDarwin
+@expectedFailureAll(archs=['i386'])
 def test_type_lookup(self):
 """Test type lookup command."""
 self.build()


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

[Lldb-commits] [lldb] r282787 - Fixed TestObjCMethods2/i386 by separating out the portions that require ObjC V2.

2016-09-29 Thread Sean Callanan via lldb-commits

Author: spyffe
Date: Thu Sep 29 16:43:31 2016
New Revision: 282787

URL: http://llvm.org/viewvc/llvm-project?rev=282787&view=rev
Log:
Fixed TestObjCMethods2/i386 by separating out the portions that require ObjC V2.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods2.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods2.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods2.py?rev=282787&r1=282786&r2=282787&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods2.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods2.py
 Thu Sep 29 16:43:31 2016
@@ -131,18 +131,18 @@ class FoundationTestCase2(TestBase):
 patterns=["\(int\) \$.* ="])
 self.expect("expression (int)[str_id length]",
 patterns=["\(int\) \$.* ="])
-self.expect("expression [str description]",
+self.expect("expression (id)[str description]",
 patterns=["\(id\) \$.* = 0x"])
 self.expect("expression (id)[str_id description]",
 patterns=["\(id\) \$.* = 0x"])
 self.expect("expression str.length")
-self.expect("expression str.description")
 self.expect('expression str = @"new"')
 self.runCmd("image lookup -t NSString")
-self.expect('expression str = [NSString stringWithCString: "new"]')
+self.expect('expression str = (id)[NSString stringWithCString: "new"]')
 self.runCmd("process continue")
 
-def test_MyString_dump(self):
+@expectedFailureAll(archs=["i[3-6]86"])
+def test_MyString_dump_with_runtime(self):
 """Test dump of a known Objective-C object by dereferencing it."""
 self.build()
 exe = os.path.join(os.getcwd(), "a.out")
@@ -159,25 +159,29 @@ class FoundationTestCase2(TestBase):
 "expression --show-types -- *my",
 patterns=[
 "\(MyString\) \$.* = ",
-"\(MyBase\)",
-"\(NSObject\)",
-"\(Class\)"])
+"\(MyBase\)"])
 self.runCmd("process continue")
 
 @expectedFailureAll(archs=["i[3-6]86"])
-def test_NSError_po(self):
-"""Test that po of the result of an unknown method doesn't require a 
cast."""
+def test_runtime_types(self):
+"""Test commands that require runtime types"""
 self.build()
 exe = os.path.join(os.getcwd(), "a.out")
 self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
 
-line = self.lines[4]
-
-lldbutil.run_break_set_by_file_and_line(
-self, "main.m", line, num_expected_locations=1, loc_exact=True)
+# Break inside Test_NSString:
+line = self.lines[2]
+lldbutil.run_break_set_by_source_regexp(
+self, "NSString tests")
 
 self.runCmd("run", RUN_SUCCEEDED)
 
+# Test_NSString:
+self.runCmd("thread backtrace")
+self.expect("expression [str length]",
+patterns=["\(NSUInteger\) \$.* ="])
+self.expect("expression str.length")
+self.expect('expression str = [NSString stringWithCString: "new"]')
 self.expect(
 'po [NSError errorWithDomain:@"Hello" code:35 
userInfo:@{@"NSDescription" : @"be completed."}]',
 substrs=[


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

[Lldb-commits] [lldb] r282790 - Add a quick note about how to build lldb with debug info using

2016-09-29 Thread Jason Molenda via lldb-commits

Author: jmolenda
Date: Thu Sep 29 16:47:15 2016
New Revision: 282790

URL: http://llvm.org/viewvc/llvm-project?rev=282790&view=rev
Log:
Add a quick note about how to build lldb with debug info using
cmake/ninja on linux/bsd systems.

Modified:
lldb/trunk/www/build.html

Modified: lldb/trunk/www/build.html
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/www/build.html?rev=282790&r1=282789&r2=282790&view=diff
==
--- lldb/trunk/www/build.html (original)
+++ lldb/trunk/www/build.html Thu Sep 29 16:47:15 2016
@@ -287,10 +287,17 @@
   ninja on your system. To build using ninja:
 
 
-  > cmake .. -G Ninja
+  > cmake ../llvm -G Ninja
   > ninja lldb
   > ninja check-lldb
 
+
+  If you want to debug the lldb that you're building -- that is, 
build it with debug info enabled -- pass
+  two additional arguments to cmake before running ninja:
+
+
+  > cmake ../llvm -G Ninja -DLLDB_EXPORT_ALL_SYMBOLS=1 
-DCMAKE_BUILD_TYPE=Debug
+
 Using CMake + Unix Makefiles
 If you do not have Ninja, you can still use CMake to generate 
Unix Makefiles that build LLDB:
 


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

[Lldb-commits] [lldb] r282794 - Don't expect new-style Objective-C literals to work on i386 with the V1 runtime.

2016-09-29 Thread Sean Callanan via lldb-commits

Author: spyffe
Date: Thu Sep 29 17:01:11 2016
New Revision: 282794

URL: http://llvm.org/viewvc/llvm-project?rev=282794&view=rev
Log:
Don't expect new-style Objective-C literals to work on i386 with the V1 runtime.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py?rev=282794&r1=282793&r2=282794&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py
 Thu Sep 29 17:01:11 2016
@@ -39,6 +39,7 @@ class ObjCNewSyntaxTestCase(TestBase):
 bugnumber='rdar://27792848')
 @unittest2.skipIf(platform.system() != "Darwin" or StrictVersion(
 '12.0.0') > platform.release(), "Only supported on Darwin 12.0.0+")
+@expectedFailureAll(archs=["i[3-6]86"])
 def test_expr(self):
 self.build()
 exe = os.path.join(os.getcwd(), "a.out")


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

[Lldb-commits] [lldb] r282803 - [CMake] LLDB/Expression needs to depend on intrinsics_gen

2016-09-29 Thread Chris Bieneman via lldb-commits

Author: cbieneman
Date: Thu Sep 29 17:55:09 2016
New Revision: 282803

URL: http://llvm.org/viewvc/llvm-project?rev=282803&view=rev
Log:
[CMake] LLDB/Expression needs to depend on intrinsics_gen

IRExecutionUnit.h includes Module.h, which through a long chain of includes 
eventually includes Attributes.gen.

This fixes a build issue reported to lldb-dev by Hal. Thanks Hal!

Modified:
lldb/trunk/source/Expression/CMakeLists.txt

Modified: lldb/trunk/source/Expression/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/CMakeLists.txt?rev=282803&r1=282802&r2=282803&view=diff
==
--- lldb/trunk/source/Expression/CMakeLists.txt (original)
+++ lldb/trunk/source/Expression/CMakeLists.txt Thu Sep 29 17:55:09 2016
@@ -15,3 +15,7 @@ add_lldb_library(lldbExpression
   UserExpression.cpp
   UtilityFunction.cpp
   )
+
+if(NOT LLDB_BUILT_STANDALONE)
+  add_dependencies(lldbExpression intrinsics_gen)
+endif()


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

[Lldb-commits] [lldb] r282810 - Add some logging when trace is on. We're getting a bot failure on i386 that doesn't

2016-09-29 Thread Jim Ingham via lldb-commits

Author: jingham
Date: Thu Sep 29 18:48:21 2016
New Revision: 282810

URL: http://llvm.org/viewvc/llvm-project?rev=282810&view=rev
Log:
Add some logging when trace is on.  We're getting a bot failure on i386 that 
doesn't 
I can't reproduce locally.  Hopefully this will help us catch the reason.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py?rev=282810&r1=282809&r2=282810&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py
 Thu Sep 29 18:48:21 2016
@@ -55,10 +55,12 @@ def is_variable_in_register(frame, var_n
 return True
 
 
-def is_struct_pointer_in_register(frame, var_name):
+def is_struct_pointer_in_register(frame, var_name, trace):
 # Ensure we can lookup the variable.
 var = frame.FindVariable(var_name)
-# print("\nchecking {}...".format(var_name))
+if trace:
+print("\nchecking {}...".format(var_name))
+
 if var is None or not var.IsValid():
 # print("{} cannot be found".format(var_name))
 return False
@@ -68,13 +70,16 @@ def is_struct_pointer_in_register(frame,
 value = var.GetValue()
 # print("checking value...")
 if value is None:
-# print("value is invalid")
+if trace:
+print("value is invalid")
 return False
-# else:
-# print("value is {}".format(value))
+else:
+if trace:
+ print("value is {}".format(value))
 
 var_loc = var.GetLocation()
-# print("checking location: {}".format(var_loc))
+if trace:
+print("checking location: {}".format(var_loc))
 if var_loc is None or var_loc.startswith("0x"):
 # The frame var is not in a register but rather a memory location.
 # print("frame var {} is not in a register".format(var_name))
@@ -94,6 +99,7 @@ class RegisterVariableTestCase(TestBase)
 mydir = TestBase.compute_mydir(__file__)
 
 @expectedFailureAll(compiler="clang", compiler_version=['<', '3.5'])
+@expectedFailureAll(compiler="clang", archs=["i386"])
 @expectedFailureAll(
 compiler="gcc", compiler_version=[
 '>=', '4.8.2'], archs=[
@@ -108,6 +114,7 @@ class RegisterVariableTestCase(TestBase)
 # way.
 register_variables_count = 0
 
+print("Trace is: ", self.TraceOn())
 self.build()
 exe = os.path.join(os.getcwd(), "a.out")
 self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
@@ -138,7 +145,7 @@ class RegisterVariableTestCase(TestBase)
 self.expect("expr a", VARIABLES_DISPLAYED_CORRECTLY,
 patterns=[re_expr_equals('int', 2)])
 
-if is_struct_pointer_in_register(frame, 'b'):
+if is_struct_pointer_in_register(frame, 'b', self.TraceOn()):
 register_variables_count += 1
 self.expect("expr b->m1", VARIABLES_DISPLAYED_CORRECTLY,
 patterns=[re_expr_equals('int', 3)])
@@ -160,7 +167,7 @@ class RegisterVariableTestCase(TestBase)
 # Try some variables that should be visible
 frame = self.dbg.GetSelectedTarget().GetProcess(
 ).GetSelectedThread().GetSelectedFrame()
-if is_struct_pointer_in_register(frame, 'b'):
+if is_struct_pointer_in_register(frame, 'b', self.TraceOn()):
 register_variables_count += 1
 self.expect("expr b->m2", VARIABLES_DISPLAYED_CORRECTLY,
 patterns=[re_expr_equals('int', 5)])


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

[Lldb-commits] [lldb] r282811 - Switch to using TEST_EQ, TEST_FALSE where appropriate.

2016-09-29 Thread Jason Molenda via lldb-commits

Author: jmolenda
Date: Thu Sep 29 18:57:33 2016
New Revision: 282811

URL: http://llvm.org/viewvc/llvm-project?rev=282811&view=rev
Log:
Switch to using TEST_EQ, TEST_FALSE where appropriate.

Modified:
lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp

Modified: 
lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp?rev=282811&r1=282810&r2=282811&view=diff
==
--- lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp 
(original)
+++ lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp 
Thu Sep 29 18:57:33 2016
@@ -164,47 +164,47 @@ TEST_F(Testx86AssemblyInspectionEngine,
 
   // 0: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8]
   UnwindPlan::RowSP row_sp = unwind_plan.GetRowForFunctionOffset(0);
-  EXPECT_TRUE(row_sp->GetOffset() == 0);
+  EXPECT_EQ(0, row_sp->GetOffset());
   EXPECT_TRUE(row_sp->GetCFAValue().GetRegisterNumber() == k_rsp);
   EXPECT_TRUE(row_sp->GetCFAValue().IsRegisterPlusOffset() == true);
-  EXPECT_TRUE(row_sp->GetCFAValue().GetOffset() == 8);
+  EXPECT_EQ(8, row_sp->GetCFAValue().GetOffset());
 
   EXPECT_TRUE(row_sp->GetRegisterInfo(k_rip, regloc));
   EXPECT_TRUE(regloc.IsAtCFAPlusOffset());
-  EXPECT_TRUE(regloc.GetOffset() == -8);
+  EXPECT_EQ(-8, regloc.GetOffset());
 
   // 1: CFA=rsp+16 => rbp=[CFA-16] rsp=CFA+0 rip=[CFA-8]
   row_sp = unwind_plan.GetRowForFunctionOffset(1);
-  EXPECT_TRUE(row_sp->GetOffset() == 1);
+  EXPECT_EQ(1, row_sp->GetOffset());
   EXPECT_TRUE(row_sp->GetCFAValue().GetRegisterNumber() == k_rsp);
   EXPECT_TRUE(row_sp->GetCFAValue().IsRegisterPlusOffset() == true);
-  EXPECT_TRUE(row_sp->GetCFAValue().GetOffset() == 16);
+  EXPECT_EQ(16, row_sp->GetCFAValue().GetOffset());
 
   EXPECT_TRUE(row_sp->GetRegisterInfo(k_rip, regloc));
   EXPECT_TRUE(regloc.IsAtCFAPlusOffset());
-  EXPECT_TRUE(regloc.GetOffset() == -8);
+  EXPECT_EQ(-8, regloc.GetOffset());
 
   // 4: CFA=rbp+16 => rbp=[CFA-16] rsp=CFA+0 rip=[CFA-8]
   row_sp = unwind_plan.GetRowForFunctionOffset(4);
-  EXPECT_TRUE(row_sp->GetOffset() == 4);
+  EXPECT_EQ(4, row_sp->GetOffset());
   EXPECT_TRUE(row_sp->GetCFAValue().GetRegisterNumber() == k_rbp);
   EXPECT_TRUE(row_sp->GetCFAValue().IsRegisterPlusOffset() == true);
-  EXPECT_TRUE(row_sp->GetCFAValue().GetOffset() == 16);
+  EXPECT_EQ(16, row_sp->GetCFAValue().GetOffset());
 
   EXPECT_TRUE(row_sp->GetRegisterInfo(k_rip, regloc));
   EXPECT_TRUE(regloc.IsAtCFAPlusOffset());
-  EXPECT_TRUE(regloc.GetOffset() == -8);
+  EXPECT_EQ(-8, regloc.GetOffset());
 
   // 7: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8]
   row_sp = unwind_plan.GetRowForFunctionOffset(7);
-  EXPECT_TRUE(row_sp->GetOffset() == 7);
+  EXPECT_EQ(7, row_sp->GetOffset());
   EXPECT_TRUE(row_sp->GetCFAValue().GetRegisterNumber() == k_rsp);
   EXPECT_TRUE(row_sp->GetCFAValue().IsRegisterPlusOffset() == true);
-  EXPECT_TRUE(row_sp->GetCFAValue().GetOffset() == 8);
+  EXPECT_EQ(8, row_sp->GetCFAValue().GetOffset());
 
   EXPECT_TRUE(row_sp->GetRegisterInfo(k_rip, regloc));
   EXPECT_TRUE(regloc.IsAtCFAPlusOffset());
-  EXPECT_TRUE(regloc.GetOffset() == -8);
+  EXPECT_EQ(-8, regloc.GetOffset());
 }
 
 TEST_F(Testx86AssemblyInspectionEngine, TestSimple32bitFrameFunction) {
@@ -240,10 +240,10 @@ TEST_F(Testx86AssemblyInspectionEngine,
 
   // offset 0 -- pushl %ebp
   UnwindPlan::RowSP row_sp = unwind_plan.GetRowForFunctionOffset(0);
-  EXPECT_TRUE(row_sp->GetOffset() == 0);
+  EXPECT_EQ(0, row_sp->GetOffset());
   EXPECT_TRUE(row_sp->GetCFAValue().GetRegisterNumber() == k_esp);
   EXPECT_TRUE(row_sp->GetCFAValue().IsRegisterPlusOffset() == true);
-  EXPECT_TRUE(row_sp->GetCFAValue().GetOffset() == 4);
+  EXPECT_EQ(4, row_sp->GetCFAValue().GetOffset());
 
   EXPECT_TRUE(row_sp->GetRegisterInfo(k_eip, regloc));
   EXPECT_TRUE(regloc.IsAtCFAPlusOffset());
@@ -251,36 +251,36 @@ TEST_F(Testx86AssemblyInspectionEngine,
 
   // 1: CFA=esp +8 => ebp=[CFA-8] esp=CFA+0 eip=[CFA-4]
   row_sp = unwind_plan.GetRowForFunctionOffset(1);
-  EXPECT_TRUE(row_sp->GetOffset() == 1);
+  EXPECT_EQ(1, row_sp->GetOffset());
   EXPECT_TRUE(row_sp->GetCFAValue().GetRegisterNumber() == k_esp);
   EXPECT_TRUE(row_sp->GetCFAValue().IsRegisterPlusOffset() == true);
-  EXPECT_TRUE(row_sp->GetCFAValue().GetOffset() == 8);
+  EXPECT_EQ(8, row_sp->GetCFAValue().GetOffset());
 
   EXPECT_TRUE(row_sp->GetRegisterInfo(k_eip, regloc));
   EXPECT_TRUE(regloc.IsAtCFAPlusOffset());
-  EXPECT_TRUE(regloc.GetOffset() == -4);
+  EXPECT_EQ(-4, regloc.GetOffset());
 
   // 3: CFA=ebp +8 => ebp=[CFA-8] esp=CFA+0 eip=[CFA-4]
   row_sp = unwind_plan.GetRowForFunctionOffset(3);
-  EXPECT_TRUE(row_sp->GetOffset() == 3);
+  EXPECT_EQ(3, row_sp->GetOffset());
   EXPECT_TRUE(row_sp->GetCFAValue().GetRegisterNumber() == k_ebp);
   EXPECT_TRUE(row_sp->GetCFAValue().IsRegiste

[Lldb-commits] [lldb] r282822 - Move UTF functions into namespace llvm.

2016-09-29 Thread Justin Lebar via lldb-commits

Author: jlebar
Date: Thu Sep 29 19:38:45 2016
New Revision: 282822

URL: http://llvm.org/viewvc/llvm-project?rev=282822&view=rev
Log:
Move UTF functions into namespace llvm.

Summary:
This lets people link against LLVM and their own version of the UTF
library.

I determined this only affects llvm, clang, lld, and lldb by running

$ git grep -wl 'UTF[0-9]\+\|\bConvertUTF\bisLegalUTF\|getNumBytesFor' | cut -f 
1 -d '/' | sort | uniq
  clang
  lld
  lldb
  llvm

Tested with

  ninja lldb
  ninja check-clang check-llvm check-lld

(ninja check-lldb doesn't complete for me with or without this patch.)

Reviewers: rnk

Subscribers: klimek, beanz, mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D24996

Modified:
lldb/trunk/source/DataFormatters/StringPrinter.cpp
lldb/trunk/source/Plugins/Process/minidump/MinidumpTypes.cpp

Modified: lldb/trunk/source/DataFormatters/StringPrinter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/DataFormatters/StringPrinter.cpp?rev=282822&r1=282821&r2=282822&view=diff
==
--- lldb/trunk/source/DataFormatters/StringPrinter.cpp (original)
+++ lldb/trunk/source/DataFormatters/StringPrinter.cpp Thu Sep 29 19:38:45 2016
@@ -133,7 +133,7 @@ GetPrintableImpl retval{nullptr};
 
-  unsigned utf8_encoded_len = getNumBytesForUTF8(*buffer);
+  unsigned utf8_encoded_len = llvm::getNumBytesForUTF8(*buffer);
 
   if (1 + buffer_end - buffer < utf8_encoded_len) {
 // I don't have enough bytes - print whatever I have left
@@ -266,9 +266,10 @@ StringPrinter::GetDefaultEscapingHelper(
 // use this call if you already have an LLDB-side buffer for the data
 template 
 static bool DumpUTFBufferToStream(
-ConversionResult (*ConvertFunction)(const SourceDataType **,
-const SourceDataType *, UTF8 **, UTF8 
*,
-ConversionFlags),
+llvm::ConversionResult (*ConvertFunction)(const SourceDataType **,
+  const SourceDataType *,
+  llvm::UTF8 **, llvm::UTF8 *,
+  llvm::ConversionFlags),
 const StringPrinter::ReadBufferAndDumpToStreamOptions &dump_options) {
   Stream &stream(*dump_options.GetStream());
   if (dump_options.GetPrefixToken() != 0)
@@ -303,30 +304,29 @@ static bool DumpUTFBufferToStream(
 }
 
 lldb::DataBufferSP utf8_data_buffer_sp;
-UTF8 *utf8_data_ptr = nullptr;
-UTF8 *utf8_data_end_ptr = nullptr;
+llvm::UTF8 *utf8_data_ptr = nullptr;
+llvm::UTF8 *utf8_data_end_ptr = nullptr;
 
 if (ConvertFunction) {
   utf8_data_buffer_sp.reset(new DataBufferHeap(4 * bufferSPSize, 0));
-  utf8_data_ptr = (UTF8 *)utf8_data_buffer_sp->GetBytes();
+  utf8_data_ptr = (llvm::UTF8 *)utf8_data_buffer_sp->GetBytes();
   utf8_data_end_ptr = utf8_data_ptr + utf8_data_buffer_sp->GetByteSize();
   ConvertFunction(&data_ptr, data_end_ptr, &utf8_data_ptr,
-  utf8_data_end_ptr, lenientConversion);
+  utf8_data_end_ptr, llvm::lenientConversion);
   if (false == zero_is_terminator)
 utf8_data_end_ptr = utf8_data_ptr;
+  // needed because the ConvertFunction will change the value of the
+  // data_ptr.
   utf8_data_ptr =
-  (UTF8 *)utf8_data_buffer_sp->GetBytes(); // needed because the
-   // ConvertFunction will
-   // change the value of the
-   // data_ptr
+  (llvm::UTF8 *)utf8_data_buffer_sp->GetBytes();
 } else {
   // just copy the pointers - the cast is necessary to make the compiler
   // happy
   // but this should only happen if we are reading UTF8 data
-  utf8_data_ptr =
-  const_cast(reinterpret_cast(data_ptr));
-  utf8_data_end_ptr =
-  const_cast(reinterpret_cast(data_end_ptr));
+  utf8_data_ptr = const_cast(
+  reinterpret_cast(data_ptr));
+  utf8_data_end_ptr = const_cast(
+  reinterpret_cast(data_end_ptr));
 }
 
 const bool escape_non_printables = dump_options.GetEscapeNonPrintables();
@@ -512,9 +512,10 @@ bool StringPrinter::ReadStringAndDumpToS
 template 
 static bool ReadUTFBufferAndDumpToStream(
 const StringPrinter::ReadStringAndDumpToStreamOptions &options,
-ConversionResult (*ConvertFunction)(const SourceDataType **,
-const SourceDataType *, UTF8 **, UTF8 
*,
-ConversionFlags)) {
+llvm::ConversionResult (*ConvertFunction)(const SourceDataType **,
+  const SourceDataType *,
+  llvm::UTF8 **, llvm::UTF8 *,
+  llv

[Lldb-commits] [lldb] r282823 - Do not assume we will be able to discover the return type of this selector call, for that is not true in i386 mode

2016-09-29 Thread Enrico Granata via lldb-commits

Author: enrico
Date: Thu Sep 29 19:40:04 2016
New Revision: 282823

URL: http://llvm.org/viewvc/llvm-project?rev=282823&view=rev
Log:
Do not assume we will be able to discover the return type of this selector 
call, for that is not true in i386 mode


Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py?rev=282823&r1=282822&r2=282823&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
 Thu Sep 29 19:40:04 2016
@@ -227,7 +227,7 @@ class ObjCDataFormatterTestCase(TestBase
 '@"21 items"'])
 
 self.expect(
-'expression -d run -- [NSArray new]',
+'expression -d run -- (NSArray*)[NSArray new]',
 substrs=['@"0 elements"'])
 
 def nsdata_data_formatter_commands(self):


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

[Lldb-commits] [lldb] r282825 - Add unit tests for simple frameless i386 and x86_64 function

2016-09-29 Thread Jason Molenda via lldb-commits

Author: jmolenda
Date: Thu Sep 29 19:41:15 2016
New Revision: 282825

URL: http://llvm.org/viewvc/llvm-project?rev=282825&view=rev
Log:
Add unit tests for simple frameless i386 and x86_64 function
instruction inspection to UnwindPlans.

Modified:
lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp

Modified: 
lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp?rev=282825&r1=282824&r2=282825&view=diff
==
--- lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp 
(original)
+++ lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp 
Thu Sep 29 19:41:15 2016
@@ -431,11 +431,230 @@ TEST_F(Testx86AssemblyInspectionEngine,
   // these could be set to IsSame and be valid -- meaning that the
   // register value is the same as the caller's -- but I'd rather
   // they not be mentioned at all.
+
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_rax, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_rbx, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_rcx, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_rdx, regloc));
   EXPECT_FALSE(row_sp->GetRegisterInfo(k_rbp, regloc));
-  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r15, regloc));
-  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r14, regloc));
-  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r13, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_rsi, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_rdi, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r8, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r9, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r10, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r11, regloc));
   EXPECT_FALSE(row_sp->GetRegisterInfo(k_r12, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r13, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r14, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r15, regloc));
+
+}
+
+
+TEST_F(Testx86AssemblyInspectionEngine, Test64bitFramelessSmallStackFrame) {
+  std::unique_ptr engine = Getx86_64Inspector();
+
+  // this source file:
+  // #include 
+  // int main () {
+  //puts ("HI");
+  // }
+  //
+  // compiled 'clang -fomit-frame-pointer' for x86_64-apple-macosx
+
+  uint8_t data[] = {
+  0x50,   
+  // offset 0  -- pushq %rax
+
+  0x48, 0x8d, 0x3d, 0x32, 0x00, 0x00, 0x00, 
+  // offset 1 -- leaq 0x32(%rip), %rdi ; "HI"
+
+  0xe8, 0x0b, 0x00, 0x00, 0x00, 
+  // offset 8 -- callq 0x10f58 ; puts
+
+  0x31, 0xc9,
+  // offset 13 -- xorl %ecx, %ecx
+  
+  0x89, 0x44, 0x24, 0x04,
+  // offset 15 -- movl %eax, 0x4(%rsp)
+
+  0x89, 0xc8,
+  // offset 19 -- movl %ecx, %eax
+
+  0x59,
+  // offset 21 -- popq %rcx
+
+  0xc3
+  // offset 22 -- retq
+  };
+
+  AddressRange sample_range(0x1000, sizeof(data));
+
+  UnwindPlan unwind_plan(eRegisterKindLLDB);
+  EXPECT_TRUE(engine->GetNonCallSiteUnwindPlanFromAssembly(
+  data, sizeof(data), sample_range, unwind_plan));
+
+  // Unwind rules should look like
+  // 0: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8] 
+  // 1: CFA=rsp+16 => rsp=CFA+0 rip=[CFA-8] 
+  //22: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8] 
+
+  UnwindPlan::Row::RegisterLocation regloc;
+
+  // grab the Row for when the prologue has finished executing:
+  // 1: CFA=rsp+16 => rsp=CFA+0 rip=[CFA-8] 
+
+  UnwindPlan::RowSP row_sp = unwind_plan.GetRowForFunctionOffset(13);
+
+  EXPECT_EQ(1, row_sp->GetOffset());
+  EXPECT_TRUE(row_sp->GetCFAValue().GetRegisterNumber() == k_rsp);
+  EXPECT_TRUE(row_sp->GetCFAValue().IsRegisterPlusOffset() == true);
+  EXPECT_EQ(16, row_sp->GetCFAValue().GetOffset());
+
+  EXPECT_TRUE(row_sp->GetRegisterInfo(k_rip, regloc));
+  EXPECT_TRUE(regloc.IsAtCFAPlusOffset());
+  EXPECT_EQ(-8, regloc.GetOffset());
+
+  // none of these were spilled
+
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_rax, regloc));
   EXPECT_FALSE(row_sp->GetRegisterInfo(k_rbx, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_rcx, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_rdx, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_rbp, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_rsi, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_rdi, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r8, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r9, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r10, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r11, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r12, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r13, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r14, regloc));
+  EXPECT_FALSE(row_sp->GetRegisterInfo(k_r15, regloc));
+
+  // grab the Row for when the epilogue has finished executing:
+  // 22: CFA=rsp +8 => rsp=CFA+0 rip=[CFA

[Lldb-commits] [lldb] r282824 - Prefer skipping over x-failing

2016-09-29 Thread Enrico Granata via lldb-commits

Author: enrico
Date: Thu Sep 29 19:41:07 2016
New Revision: 282824

URL: http://llvm.org/viewvc/llvm-project?rev=282824&view=rev
Log:
Prefer skipping over x-failing


Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py?rev=282824&r1=282823&r2=282824&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/type_lookup/TestTypeLookup.py
 Thu Sep 29 19:41:07 2016
@@ -25,7 +25,7 @@ class TypeLookupTestCase(TestBase):
 self.line = line_number('main.m', '// break here')
 
 @skipUnlessDarwin
-@expectedFailureAll(archs=['i386'])
+@skipIf(archs=['i386'])
 def test_type_lookup(self):
 """Test type lookup command."""
 self.build()


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

[Lldb-commits] [lldb] r282830 - Add the tracking radar on our end.

2016-09-29 Thread Jim Ingham via lldb-commits

Author: jingham
Date: Thu Sep 29 20:23:46 2016
New Revision: 282830

URL: http://llvm.org/viewvc/llvm-project?rev=282830&view=rev
Log:
Add the tracking radar on our end.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/break_after_join/TestBreakAfterJoin.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/break_after_join/TestBreakAfterJoin.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/break_after_join/TestBreakAfterJoin.py?rev=282830&r1=282829&r2=282830&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/break_after_join/TestBreakAfterJoin.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/break_after_join/TestBreakAfterJoin.py
 Thu Sep 29 20:23:46 2016
@@ -28,7 +28,7 @@ class BreakpointAfterJoinTestCase(TestBa
 bugnumber="llvm.org/pr15824 thread states not properly maintained")
 @expectedFailureAll(
 oslist=lldbplatformutil.getDarwinOSTriples(),
-bugnumber="llvm.org/pr15824 thread states not properly maintained")
+bugnumber="llvm.org/pr15824 thread states not properly maintained and 
")
 @expectedFailureAll(
 oslist=["freebsd"],
 bugnumber="llvm.org/pr18190 thread states not properly maintained")


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

Re: [Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of

Re: [Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of

Re: [Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of

Re: [Lldb-commits] [PATCH] D25057: Fix ARM/AArch64 Step-Over watchpoint issue remove provision for duplicate watchpoints

Re: [Lldb-commits] [lldb] r282648 - Fix an issue where libc++ changed the type information we get for std::map::iterator, rendering LLDB unable to display elements vended by an iterator

Re: [Lldb-commits] [lldb] r282648 - Fix an issue where libc++ changed the type information we get for std::map::iterator, rendering LLDB unable to display elements vended by an iterator

Re: [Lldb-commits] [lldb] r282648 - Fix an issue where libc++ changed the type information we get for std::map::iterator, rendering LLDB unable to display elements vended by an iterator

Re: [Lldb-commits] [lldb] r282648 - Fix an issue where libc++ changed the type information we get for std::map::iterator, rendering LLDB unable to display elements vended by an iterator

Re: [Lldb-commits] [lldb] r282648 - Fix an issue where libc++ changed the type information we get for std::map::iterator, rendering LLDB unable to display elements vended by an iterator

[Lldb-commits] [lldb] r282741 - To fix TestObjCMethods2/i386, allowed messaging nil ObjC objects as in x86_64.

Re: [Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of

[Lldb-commits] [lldb] r282754 - Fix an issue where, in i386 mode, the wrong values were being copied into the pair object for a single-entry NSDictionary

Re: [Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of

[Lldb-commits] [lldb] r282774 - This test will not work in i386 mode because we don't create interesting types from the ObjC runtime

[Lldb-commits] [lldb] r282787 - Fixed TestObjCMethods2/i386 by separating out the portions that require ObjC V2.

[Lldb-commits] [lldb] r282790 - Add a quick note about how to build lldb with debug info using

[Lldb-commits] [lldb] r282794 - Don't expect new-style Objective-C literals to work on i386 with the V1 runtime.

[Lldb-commits] [lldb] r282803 - [CMake] LLDB/Expression needs to depend on intrinsics_gen

[Lldb-commits] [lldb] r282810 - Add some logging when trace is on. We're getting a bot failure on i386 that doesn't

[Lldb-commits] [lldb] r282811 - Switch to using TEST_EQ, TEST_FALSE where appropriate.

[Lldb-commits] [lldb] r282822 - Move UTF functions into namespace llvm.

[Lldb-commits] [lldb] r282823 - Do not assume we will be able to discover the return type of this selector call, for that is not true in i386 mode

[Lldb-commits] [lldb] r282825 - Add unit tests for simple frameless i386 and x86_64 function

[Lldb-commits] [lldb] r282824 - Prefer skipping over x-failing

[Lldb-commits] [lldb] r282830 - Add the tracking radar on our end.

25 matches

Site Navigation

Mail list logo

Footer information