[lldb-dev] Semantics of SBValue::CreateChildAtOffset

[Pavel Labath via lldb-dev]

Hello Jim, everyone,

I recently got a question/bug report about python pretty printers 
(synthetic child providers) that I couldn't answer.


The actual script is of course more complicated, but the essence boils 
down to this.


There's a class, something like:
struct S {
  ...
  T member;
};

The pretty printer tries to print this type, and it does something like:
 def get_child_at_index(self, index):
 if index == 0:
 child = self.sbvalue.GetChildMemberWithName("child")
 return child.CreateChildAtOffset("[0]", 0, T2)


Now here comes the interesting part. The exact behaviour here depends on 
the type T. If T (and of course, in the real example this is a template) 
is  plain type, then this behaves a like a bitcast so the synthetic 
child is essentially *reinterpret_cast(&s.member).


*However*, if T is a pointer, then lldb will *dereference* it before 
performing the cast, giving something like

   *reinterpret_cast(s.member) // no &
as a result.

The first question that comes to mind is: Is this behavior intentional 
or a bug?


At first it seemed like this is too subtle to be a bug, but the more I 
though about it, the less I was sure about the CreateChildAtOffset 
function as a whole.


What I mean is, this pretty printer is essentially creating child for a 
value that it is not printing. That seems like a bad idea in general, 
although I wasn't able to observe any ill effects (e.g. when I printi 
s.member directly, I don't see any bonus children). Then I looked at 
some of the in-tree pretty-printers, and I did find this pattern at 
least two libc++ printers (libcxx.py:125 and :614), although they don't 
suffer from this ambiguity, because the values they are printing are 
always pointers.


However, that means I absolutely don't know what is the expected 
behavior here:
- Are pretty printers allowed to call CreateChildAtOffset on values they 
are not printing

- Is CreateChildAtOffset supposed to behave differently for pointer types?

I'd appreciate any insight,
Pavel
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 52263] New: cli-wrapper-mpxtable.cpp - suspicious always true comparison

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=52263

Bug ID: 52263
   Summary: cli-wrapper-mpxtable.cpp - suspicious always true
comparison
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: llvm-...@redking.me.uk
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

static void PrintBTEntry(lldb::addr_t lbound, lldb::addr_t ubound,
 uint64_t value, uint64_t meta,
 lldb::SBCommandReturnObject &result) {
  const lldb::addr_t one_cmpl64 = ~((lldb::addr_t)0);
  const lldb::addr_t one_cmpl32 = ~((uint32_t)0);

  if ((lbound == one_cmpl64 || one_cmpl32) && ubound == 0) {
result.Printf("Null bounds on map: pointer value = 0x%" PRIu64 "\n",
value);
  } else {
result.Printf("lbound = 0x%" PRIu64 ",", lbound);
result.Printf(" ubound = 0x%" PRIu64 , ubound);
result.Printf(" (pointer value = 0x%" PRIu64 ",", value);
result.Printf(" metadata = 0x%" PRIu64 ")\n", meta);
  }
}

Coverity is warning: 

  if ((lbound == one_cmpl64 || one_cmpl32) && ubound == 0) {

CID undefined (#1 of 1): Logical vs. bitwise operator
(CONSTANT_EXPRESSION_RESULT)logical_vs_bitwise: The expression lbound ==
18446744073709551615UL /* one_cmpl64 */ || true /* one_cmpl32 */ is suspicious
because it performs a Boolean operation on a constant other than 0 or 1.

Should this be:

  if ((lbound == one_cmpl64 || lbound == one_cmpl32) && ubound == 0) {

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev