Re: [lldb-dev] Patch for ValueObjectPrinter::PrintChildrenIfNeeded

2019-03-06 Thread Ted Woodward via lldb-dev 
Hi Nat!,

The best way to do this is to go to http://reviews.llvm.org .
Under Differential, click Create Diff, then paste in the raw diff for your 
patch.
We like to see a full context diff, so reviewers can easily see the full file.

More info on how to submit a patch here: http://llvm.org/docs/Contributing.html

Ted

> -Original Message-
> From: lldb-dev  On Behalf Of Nat! via lldb-
> dev
> Sent: Wednesday, March 6, 2019 8:47 AM
> To: lldb-dev@lists.llvm.org
> Subject: [EXT] [lldb-dev] Patch for ValueObjectPrinter::PrintChildrenIfNeeded
> 
> I couldn't figure out how to post a patch to reviews.llvm.org, so here it is 
> per
> email, with the hope that someone adopts it :)
> 
> Basically it's just moving the `bool print_oneline` out of the execution 
> path, if
> no children are
> 
> printed, since this value is then never used. This may not seem like a big 
> deal,
> but solves a big
> 
> problem in my debugger :)
> 
> 
> 
> ```
> 
> void ValueObjectPrinter::PrintChildrenIfNeeded(bool value_printed,
>     bool summary_printed) {
>    // this flag controls whether we tried to display a description for this
>    // object and failed if that happens, we want to display the children, if 
> any
>    bool is_failed_description =
>    !PrintObjectDescriptionIfNeeded(value_printed, summary_printed);
> 
>    auto curr_ptr_depth = m_ptr_depth;
>    bool print_children =
>    ShouldPrintChildren(is_failed_description, curr_ptr_depth);
> 
>    //
>    // DataVisualization::ShouldPrintAsOneLiner is often called for
>    // print_oneline (see below) and it is very expensive, so use an
>    // early exit, if we are not printing children (also easier to read)
>    //
>    if (!print_children) {
>      if (m_curr_depth >= m_options.m_max_depth && IsAggregate() &&
>     ShouldPrintValueObject()) {
>    m_stream->PutCString("{...}\n");
>      } else
>    m_stream->EOL();
>      return;
>    }
> 
>    //
>    // TODO: maybe move the bool print_oneline line to #1#, but its unclear to
>    // me if DataVisualization::ShouldPrintAsOneLiner can modify *m_valobj or
> not
>    //
>    bool print_oneline =
>    (curr_ptr_depth.CanAllowExpansion() || m_options.m_show_types ||
>     !m_options.m_allow_oneliner_mode || m_options.m_flat_output ||
>     (m_options.m_pointer_as_array) || m_options.m_show_location)
>    ? false
>    : DataVisualization::ShouldPrintAsOneLiner(*m_valobj);
> 
>    bool is_instance_ptr = IsInstancePointer();
>    uint64_t instance_ptr_value = LLDB_INVALID_ADDRESS;
> 
>    if (is_instance_ptr) {
>      instance_ptr_value = m_valobj->GetValueAsUnsigned(0);
>      if (m_printed_instance_pointers->count(instance_ptr_value)) {
>    // we already printed this instance-is-pointer thing, so don't expand 
> it
>    m_stream->PutCString(" {...}\n");
> 
>    // we're done here - get out fast
>    return;
>      } else
>    m_printed_instance_pointers->emplace(
>    instance_ptr_value); // remember this guy for future reference
>    }
> 
>    // #1#
>    if (print_oneline) {
>      m_stream->PutChar(' ');
>      PrintChildrenOneLiner(false);
>      m_stream->EOL();
>    } else
>      PrintChildren(value_printed, summary_printed, curr_ptr_depth); }
> 
> ```
> 
> 
> Ciao
> 
>     Nat!
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] RFC: Moving debug info parsing out of process

2019-03-06 Thread Adrian Prantl via lldb-dev 


> On Mar 6, 2019, at 9:43 AM, Zachary Turner  wrote:
> 
> 
> On Mon, Mar 4, 2019 at 10:32 AM Zachary Turner  > wrote:
> On Sat, Mar 2, 2019 at 2:56 PM Adrian Prantl  > wrote:
>> It becomes testable as an independent component, because you can just send 
>> requests to it and dump the results and see if they make sense.  Currently 
>> there is almost zero test coverage of this aspect of LLDB apart from what 
>> you can get after going through many levels of indirection via spinning up a 
>> full debug session and doing things that indirectly result in symbol queries.
> 
> You are right that the type system debug info ingestion and AST 
> reconstruction is primarily tested end-to-end.
> Do you consider this something worth addressing by testing the debug info 
> ingestion in isolation?
> 
>  Wanted to bump this thread for visibility.  If nothing else, I'm interested 
> in an answer to this question.  Because if people agree that it would be 
> valuable to test this going forward, we should work out a plan about what 
> such tests would look like and how to refactor the code appropriately to make 
> it possible.

I think it would help me a lot to have a better idea what level of abstraction 
you are imagining. Could perhaps come up with a mock-up example with some 
mad-up syntax / API for what such a test could look like? More testing is 
always desirable, of course, but I'm afraid that we might end up in a situation 
like we are with yaml2obj, where we can only test really trivial things nicely 
and all the interesting cases aren't representable at all.

-- adrian
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] RFC: Moving debug info parsing out of process

2019-03-06 Thread Zachary Turner via lldb-dev 
On Mon, Mar 4, 2019 at 10:32 AM Zachary Turner  wrote:

> On Sat, Mar 2, 2019 at 2:56 PM Adrian Prantl  wrote:
>
>>
>>- It becomes testable as an independent component, because you can
>>just send requests to it and dump the results and see if they make sense.
>>Currently there is almost zero test coverage of this aspect of LLDB apart
>>from what you can get after going through many levels of indirection via
>>spinning up a full debug session and doing things that indirectly result 
>> in
>>symbol queries.
>>
>> You are right that the type system debug info ingestion and AST
>> reconstruction is primarily tested end-to-end.
>>
> Do you consider this something worth addressing by testing the debug info
> ingestion in isolation?
>

 Wanted to bump this thread for visibility.  If nothing else, I'm
interested in an answer to this question.  Because if people agree that it
would be valuable to test this going forward, we should work out a plan
about what such tests would look like and how to refactor the code
appropriately to make it possible.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] March LLVM bay-area social is this Thursday!

2019-03-06 Thread George Burgess IV via lldb-dev 
We'll be at Tied House as usual, starting on Thursday the 7th at 7pm!

If you can, help us plan and RSVP here:
https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzfbkb/

See everyone there!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] new tool (core2yaml) + a new top-level library (Formats)

2019-03-06 Thread Zachary Turner via lldb-dev 
Well, all of the actual yamlization code in obj2yaml and yaml2obj is
library-ized, so you could always add the real code there, then have
core2yaml just link against it
On Wed, Mar 6, 2019 at 5:11 AM Pavel Labath  wrote:

> On 05/03/2019 22:52, Zachary Turner wrote:
> >
> >
> > On Tue, Mar 5, 2019 at 1:47 PM Jonas Devlieghere via lldb-dev
> > mailto:lldb-dev@lists.llvm.org>> wrote:
> >
> >
> > I don't know much about the minidump format or code, but it sounds
> > reasonable for me to have support for it in yaml2obj, which would be
> > a sufficient motivation to have the code live there. As you mention
> > in your footnote, MachO core files are already supported, and it
> > sounds like ELF could reuse a bunch of existing code as well. So
> > having everything in LLVM would give you even more symmetry. I also
> > doubt anyone would mind having more fine grained yamlization, even
> > if you cannot use it to reduce a test it's nicer to see structure
> > than a binary blob (imho). Anyway, that's just my take, I guess this
> > is more of a question for the LLVM mailing list.
> >
> > A lot of obj2yaml output is just "Section Name" / "Section Contents" and
> > then a long hex string consisting of the contents.  Since a core file is
> > an ELF file, this would already be supported for obj2yaml today (in
> > theory)
>
> Actually, even this is not true. An elf *core file* is an *elf file*,
> but it contains no sections. It contains "segments" instead. :P obj2yaml
> has absolutely no support for segments so if you try it to yamlize a
> core file, you will get an empty output.
>
> Interestingly, yaml2obj does contain some support for segments, but its
> extremely limited, and can only be used to create very simple
> "executable" files. Core files still cannot be represented there right
> now, as yaml2obj is still very section-centric.
>
>
> However, I do see the appeal in having a single tool for yamlization of
> various "object" file formats, so I am going to send an email to
> llvm-dev and see what the response is like there. I'd encourage anyone
> interested in this to voice your opinion there too.
>
> regards,
> pavel
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Patch for ValueObjectPrinter::PrintChildrenIfNeeded

2019-03-06 Thread Nat! via lldb-dev 
I couldn't figure out how to post a patch to reviews.llvm.org, so here 
it is per email, with the hope that someone adopts it :)


Basically it's just moving the `bool print_oneline` out of the execution 
path, if no children are


printed, since this value is then never used. This may not seem like a 
big deal, but solves a big


problem in my debugger :)



```

void ValueObjectPrinter::PrintChildrenIfNeeded(bool value_printed,
   bool summary_printed) {
  // this flag controls whether we tried to display a description for this
  // object and failed if that happens, we want to display the 
children, if any

  bool is_failed_description =
  !PrintObjectDescriptionIfNeeded(value_printed, summary_printed);

  auto curr_ptr_depth = m_ptr_depth;
  bool print_children =
  ShouldPrintChildren(is_failed_description, curr_ptr_depth);

  //
  // DataVisualization::ShouldPrintAsOneLiner is often called for
  // print_oneline (see below) and it is very expensive, so use an
  // early exit, if we are not printing children (also easier to read)
  //
  if (!print_children) {
    if (m_curr_depth >= m_options.m_max_depth && IsAggregate() &&
   ShouldPrintValueObject()) {
  m_stream->PutCString("{...}\n");
    } else
  m_stream->EOL();
    return;
  }

  //
  // TODO: maybe move the bool print_oneline line to #1#, but its 
unclear to
  // me if DataVisualization::ShouldPrintAsOneLiner can modify 
*m_valobj or not

  //
  bool print_oneline =
  (curr_ptr_depth.CanAllowExpansion() || m_options.m_show_types ||
   !m_options.m_allow_oneliner_mode || m_options.m_flat_output ||
   (m_options.m_pointer_as_array) || m_options.m_show_location)
  ? false
  : DataVisualization::ShouldPrintAsOneLiner(*m_valobj);

  bool is_instance_ptr = IsInstancePointer();
  uint64_t instance_ptr_value = LLDB_INVALID_ADDRESS;

  if (is_instance_ptr) {
    instance_ptr_value = m_valobj->GetValueAsUnsigned(0);
    if (m_printed_instance_pointers->count(instance_ptr_value)) {
  // we already printed this instance-is-pointer thing, so don't 
expand it

  m_stream->PutCString(" {...}\n");

  // we're done here - get out fast
  return;
    } else
  m_printed_instance_pointers->emplace(
  instance_ptr_value); // remember this guy for future reference
  }

  // #1#
  if (print_oneline) {
    m_stream->PutChar(' ');
    PrintChildrenOneLiner(false);
    m_stream->EOL();
  } else
    PrintChildren(value_printed, summary_printed, curr_ptr_depth);
}

```


Ciao

   Nat!

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

Re: [lldb-dev] new tool (core2yaml) + a new top-level library (Formats)

2019-03-06 Thread Pavel Labath via lldb-dev 

On 05/03/2019 22:52, Zachary Turner wrote:



On Tue, Mar 5, 2019 at 1:47 PM Jonas Devlieghere via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:



I don't know much about the minidump format or code, but it sounds
reasonable for me to have support for it in yaml2obj, which would be
a sufficient motivation to have the code live there. As you mention
in your footnote, MachO core files are already supported, and it
sounds like ELF could reuse a bunch of existing code as well. So
having everything in LLVM would give you even more symmetry. I also
doubt anyone would mind having more fine grained yamlization, even
if you cannot use it to reduce a test it's nicer to see structure
than a binary blob (imho). Anyway, that's just my take, I guess this
is more of a question for the LLVM mailing list.

A lot of obj2yaml output is just "Section Name" / "Section Contents" and 
then a long hex string consisting of the contents.  Since a core file is 
an ELF file, this would already be supported for obj2yaml today (in 
theory)


Actually, even this is not true. An elf *core file* is an *elf file*, 
but it contains no sections. It contains "segments" instead. :P obj2yaml 
has absolutely no support for segments so if you try it to yamlize a 
core file, you will get an empty output.


Interestingly, yaml2obj does contain some support for segments, but its 
extremely limited, and can only be used to create very simple 
"executable" files. Core files still cannot be represented there right 
now, as yaml2obj is still very section-centric.



However, I do see the appeal in having a single tool for yamlization of 
various "object" file formats, so I am going to send an email to 
llvm-dev and see what the response is like there. I'd encourage anyone 
interested in this to voice your opinion there too.


regards,
pavel
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev