Re: [Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion

[Jason Molenda via lldb-commits]

Ah, no.  Pavel suggested that the unwind plan unittests should be turned into 
FileCheck tests, and then Davide suggested that he'd heard unwind testing is 
difficult (he was conflating the unwind sources -> UnwindPlan IR conversions 
and the runtime use of UnwindPlans to walk the stack & find spilled registers), 
so he thought that this FileCheck could help there.  I was clarifying that (1) 
I don't want the existing tests I wrote changed out of unittests, and (2) 
FileCheck does not help the actually difficult part of testing the unwinder at 
all.  I provided an example of why this was difficult, outlining the possible 
approaches, and saying that if you were doing it today, you would need to do it 
with hand written assembly, and you suggested that a process mock style 
approach would be awesome, which was one of the approaches I described in my 
original email.

> On Feb 12, 2018, at 2:18 PM, Zachary Turner  wrote:
> 
> Sure I don’t think anyone disputes that, but I thought we were discussing an 
> ideal end state
> On Mon, Feb 12, 2018 at 1:31 PM Jason Molenda  wrote:
> 
> 
> > On Feb 12, 2018, at 12:59 PM, Zachary Turner  wrote:
> >
> >
> >
> > On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda  wrote:
> >>
> >>
> >> > On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator 
> >> >  wrote:
> >> >
> >> > zturner added a comment.
> >> >
> >> > In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote:
> >> >
> >> > I don't think we'd necessarily need a live register context or stack 
> >> > memory.  A mock register context and stack memory should be sufficient, 
> >> > with an emulator that understands only a handful of instructions.
> >>
> >>
> >> That's ... exactly what I said?  That we need to mock up memory and 
> >> registers and symbols, or have a corefile and binary, or have hand written 
> >> assembly routines that set up a particular stack and an SB API test that 
> >> tries to backtrace out of it with a live process.  After the inferior 
> >> process state has been constructed/reconstituted, is the unwinder capable 
> >> of walking the stack or finding spilled registers by following the correct 
> >> UnwindPlans.  This is right in the wheelhouse of SB API testing.
> >
> > I'm saying we shouldn't need a live process (and in fact we can test it 
> > better if we don't rely on a live process, since we can write tests that 
> > run anywhere).
> 
> 
> Yes, as we've all agreed many times for years, a ProcessMock style Process 
> plugin which can fake up state from a yaml file would be a great addition -- 
> and for the unwind tests, we need a way to provide symbolic information and 
> possibly even eh_frame information from the "binaries", and maybe even a way 
> to construct the yaml representation from an actual debug session.  No one is 
> disagreeing with this.
> 
> But the fact that no one has had time to develop this plugin means that if I 
> want to write an unwind test today, I either need to allocate time to write 
> the above infrastructure first, or write the test given the tools we have 
> available to us today.
> 
> An unwind test that only runs on x86_64, or even only runs on x86_64 Darwin, 
> is not ideal, but it is much better than no test at all especially in the 
> world of buildbots that can flag a problem with a change right away.
> 
> J

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

Re: [Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion

[Zachary Turner via lldb-commits]

Sure I don’t think anyone disputes that, but I thought we were discussing
an ideal end state
On Mon, Feb 12, 2018 at 1:31 PM Jason Molenda  wrote:

>
>
> > On Feb 12, 2018, at 12:59 PM, Zachary Turner  wrote:
> >
> >
> >
> > On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda 
> wrote:
> >>
> >>
> >> > On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator <
> revi...@reviews.llvm.org> wrote:
> >> >
> >> > zturner added a comment.
> >> >
> >> > In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote:
> >> >
> >> > I don't think we'd necessarily need a live register context or stack
> memory.  A mock register context and stack memory should be sufficient,
> with an emulator that understands only a handful of instructions.
> >>
> >>
> >> That's ... exactly what I said?  That we need to mock up memory and
> registers and symbols, or have a corefile and binary, or have hand written
> assembly routines that set up a particular stack and an SB API test that
> tries to backtrace out of it with a live process.  After the inferior
> process state has been constructed/reconstituted, is the unwinder capable
> of walking the stack or finding spilled registers by following the correct
> UnwindPlans.  This is right in the wheelhouse of SB API testing.
> >
> > I'm saying we shouldn't need a live process (and in fact we can test it
> better if we don't rely on a live process, since we can write tests that
> run anywhere).
>
>
> Yes, as we've all agreed many times for years, a ProcessMock style Process
> plugin which can fake up state from a yaml file would be a great addition
> -- and for the unwind tests, we need a way to provide symbolic information
> and possibly even eh_frame information from the "binaries", and maybe even
> a way to construct the yaml representation from an actual debug session.
> No one is disagreeing with this.
>
> But the fact that no one has had time to develop this plugin means that if
> I want to write an unwind test today, I either need to allocate time to
> write the above infrastructure first, or write the test given the tools we
> have available to us today.
>
> An unwind test that only runs on x86_64, or even only runs on x86_64
> Darwin, is not ideal, but it is much better than no test at all especially
> in the world of buildbots that can flag a problem with a change right away.
>
> J
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion

[Jason Molenda via lldb-commits]

> On Feb 12, 2018, at 12:59 PM, Zachary Turner  wrote:
> 
> 
> 
> On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda  wrote:
>> 
>> 
>> > On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator 
>> >  wrote:
>> >
>> > zturner added a comment.
>> >
>> > In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote:
>> >
>> > I don't think we'd necessarily need a live register context or stack 
>> > memory.  A mock register context and stack memory should be sufficient, 
>> > with an emulator that understands only a handful of instructions.
>> 
>> 
>> That's ... exactly what I said?  That we need to mock up memory and 
>> registers and symbols, or have a corefile and binary, or have hand written 
>> assembly routines that set up a particular stack and an SB API test that 
>> tries to backtrace out of it with a live process.  After the inferior 
>> process state has been constructed/reconstituted, is the unwinder capable of 
>> walking the stack or finding spilled registers by following the correct 
>> UnwindPlans.  This is right in the wheelhouse of SB API testing.
> 
> I'm saying we shouldn't need a live process (and in fact we can test it 
> better if we don't rely on a live process, since we can write tests that run 
> anywhere).


Yes, as we've all agreed many times for years, a ProcessMock style Process 
plugin which can fake up state from a yaml file would be a great addition -- 
and for the unwind tests, we need a way to provide symbolic information and 
possibly even eh_frame information from the "binaries", and maybe even a way to 
construct the yaml representation from an actual debug session.  No one is 
disagreeing with this.

But the fact that no one has had time to develop this plugin means that if I 
want to write an unwind test today, I either need to allocate time to write the 
above infrastructure first, or write the test given the tools we have available 
to us today.  

An unwind test that only runs on x86_64, or even only runs on x86_64 Darwin, is 
not ideal, but it is much better than no test at all especially in the world of 
buildbots that can flag a problem with a change right away.

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

Re: [Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion

[Zachary Turner via lldb-commits]

On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda  wrote:

>
>
> > On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator <
> revi...@reviews.llvm.org> wrote:
> >
> > zturner added a comment.
> >
> > In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote:
> >
> > I don't think we'd necessarily need a live register context or stack
> memory.  A mock register context and stack memory should be sufficient,
> with an emulator that understands only a handful of instructions.
>
>
> That's ... exactly what I said?  That we need to mock up memory and
> registers and symbols, or have a corefile and binary, or have hand written
> assembly routines that set up a particular stack and an SB API test that
> tries to backtrace out of it with a live process.  After the inferior
> process state has been constructed/reconstituted, is the unwinder capable
> of walking the stack or finding spilled registers by following the correct
> UnwindPlans.  This is right in the wheelhouse of SB API testing.
>

I'm saying we shouldn't need a live process (and in fact we can test it
better if we don't rely on a live process, since we can write tests that
run anywhere).
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion

[Jason Molenda via lldb-commits]

> On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator 
>  wrote:
> 
> zturner added a comment.
> 
> In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote:
> 
>> No, the unwind unittests that exist today should stay written as unit tests. 
>>  These are testing the conversion of native unwind formats -- for instance, 
>> eh_frame, compact unwind, or instruction analysis -- into the intermediate 
>> UnwindPlan representation in lldb.  They are runtime invariant, unit tests 
>> are the best approach to these.  If there were anything to say about these, 
>> it would be that we need more testing here - armv7 (AArch32) into UnwindPlan 
>> is not tested.  eh_frame and compact_unwind into UnwindPlan is not tested.
> 
> 
> That's exactly the type of thing that FileCheck tests work best for.  I'm not 
> sure why you're saying that unittests are better than FileCheck tests for 
> this scenario.


I'm saying that the unittests here are entirely appropriate, and that rewriting 
existing tests in FileCheck style doesn't make any sense to me.  If people want 
to write new tests using that style, that's fine I guess, but I wrote these 
tests for a part of lldb that I maintain and I'd prefer to keep them as-is.


> 
>> The part of unwind that is difficult to test is the runtime unwind behavior, 
>> and FileCheck style tests don't make that easier in any way.  We need a live 
>> register context, stack memory, symbols and UnwindPlans to test this 
>> correctly -- we either need a full ProcessMock with SymbolVendorMock etc, or 
>> we need corefiles, or we need tests with hand-written assembly code.
> 
> I don't think we'd necessarily need a live register context or stack memory.  
> A mock register context and stack memory should be sufficient, with an 
> emulator that understands only a handful of instructions.


That's ... exactly what I said?  That we need to mock up memory and registers 
and symbols, or have a corefile and binary, or have hand written assembly 
routines that set up a particular stack and an SB API test that tries to 
backtrace out of it with a live process.  After the inferior process state has 
been constructed/reconstituted, is the unwinder capable of walking the stack or 
finding spilled registers by following the correct UnwindPlans.  This is right 
in the wheelhouse of SB API testing.

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

[Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote:

> No, the unwind unittests that exist today should stay written as unit tests.  
> These are testing the conversion of native unwind formats -- for instance, 
> eh_frame, compact unwind, or instruction analysis -- into the intermediate 
> UnwindPlan representation in lldb.  They are runtime invariant, unit tests 
> are the best approach to these.  If there were anything to say about these, 
> it would be that we need more testing here - armv7 (AArch32) into UnwindPlan 
> is not tested.  eh_frame and compact_unwind into UnwindPlan is not tested.


That's exactly the type of thing that FileCheck tests work best for.  I'm not 
sure why you're saying that unittests are better than FileCheck tests for this 
scenario.

> The part of unwind that is difficult to test is the runtime unwind behavior, 
> and FileCheck style tests don't make that easier in any way.  We need a live 
> register context, stack memory, symbols and UnwindPlans to test this 
> correctly -- we either need a full ProcessMock with SymbolVendorMock etc, or 
> we need corefiles, or we need tests with hand-written assembly code.

I don't think we'd necessarily need a live register context or stack memory.  A 
mock register context and stack memory should be sufficient, with an emulator 
that understands only a handful of instructions.


https://reviews.llvm.org/D43048



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

[Lldb-commits] [PATCH] D43202: Remove dead code for handling DWARF pubnames

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

I also had to remove them from the Xcode project.  With that done everything 
looks good.


Repository:
  rL LLVM

https://reviews.llvm.org/D43202



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

[Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

No, the unwind unittests that exist today should stay written as unit tests.  
These are testing the conversion of native unwind formats -- for instance, 
eh_frame, compact unwind, or instruction analysis -- into the intermediate 
UnwindPlan representation in lldb.  They are runtime invariant, unit tests are 
the best approach to these.  If there were anything to say about these, it 
would be that we need more testing here - armv7 (AArch32) into UnwindPlan is 
not tested.  eh_frame and compact_unwind into UnwindPlan is not tested.

The part of unwind that is difficult to test is the runtime unwind behavior, 
and FileCheck style tests don't make that easier in any way.  We need a live 
register context, stack memory, symbols and UnwindPlans to test this correctly 
-- we either need a full ProcessMock with SymbolVendorMock etc, or we need 
corefiles, or we need tests with hand-written assembly code.

I'm leaning towards starting to write C test cases with hand written assembly 
routines that set up their stacks in unusual ways to test the unwinder, I've 
written unwind testsuites in the past in this way and it works well but it does 
mean that you need to be on the arch (and possibly even the OS) that the test 
is written in -- bots will show the failures for everyone after a commit goes 
in, at least.  But these will be written as SB API tests.


https://reviews.llvm.org/D43048



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

Re: [Lldb-commits] [PATCH] D43099: Make LLDB's clang module cache path customizable

[Jim Ingham via lldb-commits]

Thanks for laying this out.  I don't think any of us have a brief for getopt, 
it was the tool at hand.  Getting some fuzzy match suggestions would be nice.

Your comment about getopts reminds me, a more fundamental problem with lldb's 
command interpreter is that the CommandObject is stateful.  So you can't 
actually call a command and then in the process of handling that command call 
back into the same command without destroying the options settings from the 
older invocation.  We actually do this  (e.g. anything that hits a breakpoint 
can call arbitrary lldb commands).  We just luck out because most commands grab 
their arguments, decide what to do with them, then do the work.  So the second 
invocation overwrites options that aren't going to get reused.  But working by 
luck is never good...

It would be much better to separate the Command definition part of the 
CommandObject from the Invocation part, so that one command definition could 
server multiple invocations.  If somebody has ambition to dig into lldb's 
command interpreter, I'd propose this task over replacing something that works 
with something else that works more nicely.

Jim


> On Feb 12, 2018, at 2:31 AM, Pavel Labath via Phabricator 
>  wrote:
> 
> labath added a comment.
> 
> There are several components in the "command line parsing"
> 
> 1. argparse: parsing a single string into the individual words (processing 
> quotes, backslashes, etc.)
> 2. resolving the "command" part of the command line (the "frame variable" 
> part of "frame variable --raw-output FOO")
> 3. resolving the arguments of a command (the "--raw-output FOO" part)
> 
> These parts compose quite nicely, and can be individually replaced. I'll 
> briefly speak about each one :
> 
> (1) is very specific to our interactive use case (for command line utilities, 
> the shell/os does the parsing for us). There also isn't anything nearly 
> similar in llvm (afaik).
> (2) is also quite specific to how lldb commands are structured, and there 
> also isn't a suitable llvm replacement. This is the level at which the 
> "command aliases" are resolved.
> (3) is a fairly generic piece of functionality -- we even implement it by 
> delegating to getopt (in a scarily un-thread-safe way). For this there are 
> *two* competing implementations in llvm: `llvm::cl` and `llvm::opt`. Of these 
> the first one is not suitable for our use case right now as it relies on 
> global variables. Making it work probably would be a bit or work. However, 
> using the second one should be fairly easy, and it should be generic-enough 
> (it's the thing that handles crazy gcc command lines).
> 
> The reason I'm spelling it out this way is because I think you were mostly 
> talking about (3), but some of the difficulties Jim pointed out (command 
> aliases) just aren't relevant there.  I don't think llvm::opt handles 
> "shortest match" options yet, but that should be fairly easy to add.  On the 
> flip side, the library has recently gained argument suggestion capabilities 
> (`error: unknown argument '-gllbb', did you mean '-glldb'`), so we would get 
> that for free. Making sure tab completion works there would require a bit of 
> thought, but I think this should not interfere with this library too much 
> (after all, we use getopt now, and it does not support tab completion either).
> 
> 
> Repository:
>  rL LLVM
> 
> https://reviews.llvm.org/D43099
> 
> 
> 

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

[Lldb-commits] [lldb] r324925 - Remove dead code for handling DWARF pubnames

[Adrian McCarthy via lldb-commits]

Author: amccarth
Date: Mon Feb 12 11:19:04 2018
New Revision: 324925

URL: http://llvm.org/viewvc/llvm-project?rev=324925=rev
Log:
Remove dead code for handling DWARF pubnames

Summary:
LLDB doesn't use this code, the code has no tests, and the code does suspicious
things like hashing pointers to strings instead of the strings themselves.

Subscribers: sanjoy, mgorny, JDevlieghere

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

Removed:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.h
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt?rev=324925=324924=324925=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt Mon Feb 12 
11:19:04 2018
@@ -17,8 +17,6 @@ add_lldb_library(lldbPluginSymbolFileDWA
   DWARFDebugMacro.cpp
   DWARFDebugMacinfo.cpp
   DWARFDebugMacinfoEntry.cpp
-  DWARFDebugPubnames.cpp
-  DWARFDebugPubnamesSet.cpp
   DWARFDebugRanges.cpp
   DWARFDeclContext.cpp
   DWARFDefines.cpp

Removed: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp?rev=324924=auto
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp (removed)
@@ -1,255 +0,0 @@
-//===-- DWARFDebugPubnames.cpp --*- C++ 
-*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-
-#include "DWARFDebugPubnames.h"
-
-#include "lldb/Utility/Stream.h"
-#include "lldb/Utility/Timer.h"
-
-#include "DWARFCompileUnit.h"
-#include "DWARFDIECollection.h"
-#include "DWARFDebugInfo.h"
-#include "DWARFFormValue.h"
-#include "LogChannelDWARF.h"
-#include "SymbolFileDWARF.h"
-
-using namespace lldb;
-using namespace lldb_private;
-
-DWARFDebugPubnames::DWARFDebugPubnames() : m_sets() {}
-
-bool DWARFDebugPubnames::Extract(const DWARFDataExtractor ) {
-  static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
-  Timer scoped_timer(func_cat,
- "DWARFDebugPubnames::Extract (byte_size = %" PRIu64 ")",
- (uint64_t)data.GetByteSize());
-  Log *log(LogChannelDWARF::GetLogIfAll(DWARF_LOG_DEBUG_PUBNAMES));
-  if (log)
-log->Printf("DWARFDebugPubnames::Extract (byte_size = %" PRIu64 ")",
-(uint64_t)data.GetByteSize());
-
-  if (data.ValidOffset(0)) {
-lldb::offset_t offset = 0;
-
-DWARFDebugPubnamesSet set;
-while (data.ValidOffset(offset)) {
-  if (set.Extract(data, )) {
-m_sets.push_back(set);
-offset = set.GetOffsetOfNextEntry();
-  } else
-break;
-}
-if (log)
-  Dump(log);
-return true;
-  }
-  return false;
-}
-
-bool DWARFDebugPubnames::GeneratePubnames(SymbolFileDWARF *dwarf2Data) {
-  static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
-  Timer scoped_timer(func_cat,
- "DWARFDebugPubnames::GeneratePubnames (data = %p)",
- static_cast(dwarf2Data));
-
-  Log *log(LogChannelDWARF::GetLogIfAll(DWARF_LOG_DEBUG_PUBNAMES));
-  if (log)
-log->Printf("DWARFDebugPubnames::GeneratePubnames (data = %p)",
-static_cast(dwarf2Data));
-
-  m_sets.clear();
-  DWARFDebugInfo *debug_info = dwarf2Data->DebugInfo();
-  if (debug_info) {
-uint32_t cu_idx = 0;
-const uint32_t num_compile_units = dwarf2Data->GetNumCompileUnits();
-for (cu_idx = 0; cu_idx < num_compile_units; ++cu_idx) {
-
-  DWARFCompileUnit *cu = debug_info->GetCompileUnitAtIndex(cu_idx);
-
-  DWARFFormValue::FixedFormSizes fixed_form_sizes =
-  DWARFFormValue::GetFixedFormSizesForAddressSize(
-  cu->GetAddressByteSize(), cu->IsDWARF64());
-
-  bool clear_dies = cu->ExtractDIEsIfNeeded(false) > 1;
-
-  DWARFDIECollection dies;
-  const size_t die_count = cu->AppendDIEsWithTag(DW_TAG_subprogram, dies) +
-   cu->AppendDIEsWithTag(DW_TAG_variable, dies);
-
-  dw_offset_t cu_offset = 

[Lldb-commits] [PATCH] D43202: Remove dead code for handling DWARF pubnames

[Adrian McCarthy via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL324925: Remove dead code for handling DWARF pubnames 
(authored by amccarth, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D43202?vs=133903=133906#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D43202

Files:
  lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.h
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.cpp
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.h
  lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h

Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -65,7 +65,6 @@
 #include "DWARFDebugInfo.h"
 #include "DWARFDebugLine.h"
 #include "DWARFDebugMacro.h"
-#include "DWARFDebugPubnames.h"
 #include "DWARFDebugRanges.h"
 #include "DWARFDeclContext.h"
 #include "DWARFFormValue.h"
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
@@ -17,8 +17,6 @@
   DWARFDebugMacro.cpp
   DWARFDebugMacinfo.cpp
   DWARFDebugMacinfoEntry.cpp
-  DWARFDebugPubnames.cpp
-  DWARFDebugPubnamesSet.cpp
   DWARFDebugRanges.cpp
   DWARFDeclContext.cpp
   DWARFDefines.cpp
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
@@ -54,7 +54,6 @@
 class DWARFDebugInfo;
 class DWARFDebugInfoEntry;
 class DWARFDebugLine;
-class DWARFDebugPubnames;
 class DWARFDebugRanges;
 class DWARFDeclContext;
 class DWARFDIECollection;
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.cpp
@@ -1,146 +0,0 @@
-//===-- DWARFDebugPubnamesSet.cpp ---*- C++ -*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-
-#include "DWARFDebugPubnamesSet.h"
-
-#include "lldb/Utility/Log.h"
-#include "lldb/Utility/RegularExpression.h"
-
-#include "SymbolFileDWARF.h"
-
-using namespace lldb_private;
-
-DWARFDebugPubnamesSet::DWARFDebugPubnamesSet()
-: m_offset(DW_INVALID_OFFSET), m_header(), m_descriptors(),
-  m_name_to_descriptor_index() {}
-
-DWARFDebugPubnamesSet::DWARFDebugPubnamesSet(dw_offset_t debug_aranges_offset,
- dw_offset_t cu_die_offset,
- dw_offset_t cu_die_length)
-: m_offset(debug_aranges_offset), m_header(), m_descriptors(),
-  m_name_to_descriptor_index() {
-  m_header.length =
-  10; // set the length to only include the header right for now
-  m_header.version = 2;// The DWARF version number
-  m_header.die_offset = cu_die_offset; // compile unit .debug_info offset
-  m_header.die_length = cu_die_length; // compile unit .debug_info length
-}
-
-void DWARFDebugPubnamesSet::AddDescriptor(dw_offset_t cu_rel_offset,
-  const char *name) {
-  if (name && name[0]) {
-// Adjust our header length
-m_header.length += strlen(name) + 1 + sizeof(dw_offset_t);
-Descriptor pubnameDesc(cu_rel_offset, name);
-m_descriptors.push_back(pubnameDesc);
-  }
-}
-
-void DWARFDebugPubnamesSet::Clear() {
-  m_offset = DW_INVALID_OFFSET;
-  m_header.length = 10;
-  m_header.version = 2;
-  m_header.die_offset = DW_INVALID_OFFSET;
-  m_header.die_length = 0;
-  m_descriptors.clear();
-}
-
-//--
-// InitNameIndexes
-//--
-void DWARFDebugPubnamesSet::InitNameIndexes() const {
-  // Create the name index vector to be able to quickly search by name
-  const size_t count = m_descriptors.size();
-  for (uint32_t idx = 0; idx < count; ++idx) {
-const char *name = m_descriptors[idx].name.c_str();
-if (name && name[0])
-  

[Lldb-commits] [PATCH] D43096: [lit] Update how clang and other binaries are found in per-configuration directories

[Aaron Smith via Phabricator via lldb-commits]

asmith updated this revision to Diff 133899.
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D43096

Files:
  CMakeLists.txt
  lit/CMakeLists.txt
  lit/lit.site.cfg.in


Index: lit/lit.site.cfg.in
===
--- lit/lit.site.cfg.in
+++ lit/lit.site.cfg.in
@@ -6,8 +6,8 @@
 config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
 config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
 config.lldb_obj_root = "@LLDB_BINARY_DIR@"
-config.lldb_libs_dir = "@LLVM_LIBRARY_OUTPUT_INTDIR@"
-config.lldb_tools_dir = "@LLVM_RUNTIME_OUTPUT_INTDIR@"
+config.lldb_libs_dir = "@LLDB_LIBS_DIR@"
+config.lldb_tools_dir = "@LLDB_TOOLS_DIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.python_executable = "@PYTHON_EXECUTABLE@"
 config.cc = "@LLDB_TEST_C_COMPILER@"
@@ -19,6 +19,10 @@
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
 config.llvm_libs_dir = config.llvm_libs_dir % lit_config.params
+config.lldb_libs_dir = config.lldb_libs_dir % lit_config.params
+config.lldb_tools_dir = config.lldb_tools_dir % lit_config.params
+config.cc = config.cc % lit_config.params
+config.cxx = config.cxx % lit_config.params
 except KeyError as e:
 key, = e.args
 lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" % 
(key,key))
Index: lit/CMakeLists.txt
===
--- lit/CMakeLists.txt
+++ lit/CMakeLists.txt
@@ -1,10 +1,23 @@
-set(LLVM_SOURCE_DIR "${LLVM_MAIN_SRC_DIR}")
-set(LLVM_BINARY_DIR "${LLVM_BINARY_DIR}")
-set(LLVM_BUILD_MODE "%(build_mode)s")
-set(LLVM_TOOLS_DIR "${LLVM_TOOLS_BINARY_DIR}/%(build_config)s")
-set(LLVM_LIBS_DIR 
"${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/%(build_config)s")
-set(CLANG_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/..")
-set(CLANG_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}/..")
+# Test runner infrastructure for LLDB. This configures the LLDB test trees
+# for use by Lit, and delegates to LLVM's lit test handlers.
+
+if (CMAKE_CFG_INTDIR STREQUAL ".")
+  set(LLVM_BUILD_MODE ".")
+else ()
+  set(LLVM_BUILD_MODE "%(build_mode)s")
+endif ()
+
+if (NOT LLDB_TEST_USE_CUSTOM_C_COMPILER)
+  string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_C_COMPILER 
${LLDB_TEST_C_COMPILER})
+endif ()
+
+if (NOT LLDB_TEST_USE_CUSTOM_CXX_COMPILER)
+  string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_CXX_COMPILER 
${LLDB_TEST_CXX_COMPILER})
+endif ()
+
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_LIBS_DIR 
${LLVM_LIBRARY_OUTPUT_INTDIR})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TOOLS_DIR 
${LLVM_RUNTIME_OUTPUT_INTDIR})
+
 if(BUILD_SHARED_LIBS)
   set(ENABLE_SHARED 1)
 else()
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -61,12 +61,18 @@
 
 option(LLDB_INCLUDE_TESTS "Generate build targets for the LLDB unit tests."
   ${LLVM_INCLUDE_TESTS})
+option(LLDB_TEST_USE_CUSTOM_C_COMPILER "Use the C compiler provided via 
LLDB_TEST_C_COMPILER for building test inferiors (instead of the just-built 
compiler). Defaults to OFF." OFF)
+option(LLDB_TEST_USE_CUSTOM_CXX_COMPILER "Use the C++ compiler provided via 
LLDB_TEST_CXX_COMPILER for building test inferiors (instead of the just-built 
compiler). Defaults to OFF." OFF)
 if(LLDB_INCLUDE_TESTS)
-  if (TARGET clang)
+  if (NOT LLDB_TEST_USE_CUSTOM_C_COMPILER AND TARGET clang)
 set(LLDB_DEFAULT_TEST_C_COMPILER 
"${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/clang${CMAKE_EXECUTABLE_SUFFIX}")
-set(LLDB_DEFAULT_TEST_CXX_COMPILER 
"${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/clang++${CMAKE_EXECUTABLE_SUFFIX}")
   else()
 set(LLDB_DEFAULT_TEST_C_COMPILER "")
+  endif()
+
+  if (NOT LLDB_TEST_USE_CUSTOM_CXX_COMPILER AND TARGET clang)
+set(LLDB_DEFAULT_TEST_CXX_COMPILER 
"${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/clang++${CMAKE_EXECUTABLE_SUFFIX}")
+  else()
 set(LLDB_DEFAULT_TEST_CXX_COMPILER "")
   endif()
 


Index: lit/lit.site.cfg.in
===
--- lit/lit.site.cfg.in
+++ lit/lit.site.cfg.in
@@ -6,8 +6,8 @@
 config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
 config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
 config.lldb_obj_root = "@LLDB_BINARY_DIR@"
-config.lldb_libs_dir = "@LLVM_LIBRARY_OUTPUT_INTDIR@"
-config.lldb_tools_dir = "@LLVM_RUNTIME_OUTPUT_INTDIR@"
+config.lldb_libs_dir = "@LLDB_LIBS_DIR@"
+config.lldb_tools_dir = "@LLDB_TOOLS_DIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.python_executable = "@PYTHON_EXECUTABLE@"
 config.cc = "@LLDB_TEST_C_COMPILER@"
@@ -19,6 +19,10 @@
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
 config.llvm_libs_dir = config.llvm_libs_dir % lit_config.params
+config.lldb_libs_dir = config.lldb_libs_dir % lit_config.params
+config.lldb_tools_dir = config.lldb_tools_dir % lit_config.params
+config.cc = 

[Lldb-commits] [lldb] r324919 - [testsuite] Reintroduce test to check leaking.

[Davide Italiano via lldb-commits]

Author: davide
Date: Mon Feb 12 10:06:34 2018
New Revision: 324919

URL: http://llvm.org/viewvc/llvm-project?rev=324919=rev
Log:
[testsuite] Reintroduce test to check leaking.

It wasn't python leaking, it was lldb. Thanks to Pavel for the
explanation. Pointy-hat to me.

Added:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile

lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/main.c

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile?rev=324919=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile
 Mon Feb 12 10:06:34 2018
@@ -0,0 +1,5 @@
+LEVEL = ../../make
+
+C_SOURCES := main.c
+
+include $(LEVEL)/Makefile.rules

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py?rev=324919=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py
 Mon Feb 12 10:06:34 2018
@@ -0,0 +1,108 @@
+"""
+Test whether a process started by lldb has no extra file descriptors open.
+"""
+
+from __future__ import print_function
+
+
+import os
+import lldb
+from lldbsuite.test import lldbutil
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+
+
+def python_leaky_fd_version(test):
+import sys
+# Python random module leaks file descriptors on some versions.
+if sys.version_info >= (2, 7, 8) and sys.version_info < (2, 7, 10):
+return "Python random module leaks file descriptors in this python 
version"
+return None
+
+
+class AvoidsFdLeakTestCase(TestBase):
+
+NO_DEBUG_INFO_TESTCASE = True
+
+mydir = TestBase.compute_mydir(__file__)
+
+@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376")
+@expectedFailureAll(
+oslist=['freebsd'],
+bugnumber="llvm.org/pr25624 still failing with Python 2.7.10")
+# The check for descriptor leakage needs to be implemented differently
+# here.
+@skipIfWindows
+@skipIfTargetAndroid()  # Android have some other file descriptors open by 
the shell
+@skipIfDarwinEmbedded #   # debugserver on ios 
has an extra fd open on launch
+def test_fd_leak_basic(self):
+self.do_test([])
+
+@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376")
+@expectedFailureAll(
+oslist=['freebsd'],
+bugnumber="llvm.org/pr25624 still failing with Python 2.7.10")
+# The check for descriptor leakage needs to be implemented differently
+# here.
+@skipIfWindows
+@skipIfTargetAndroid()  # Android have some other file descriptors open by 
the shell
+@skipIfDarwinEmbedded #   # debugserver on ios 
has an extra fd open on launch
+def test_fd_leak_log(self):
+self.do_test(["log enable -f '/dev/null' lldb commands"])
+
+def do_test(self, commands):
+self.build()
+exe = self.getBuildArtifact("a.out")
+
+for c in commands:
+self.runCmd(c)
+
+target = self.dbg.CreateTarget(exe)
+
+process = target.LaunchSimple(
+None, None, self.get_process_working_directory())
+self.assertTrue(process, PROCESS_IS_VALID)
+
+self.assertTrue(
+process.GetState() == lldb.eStateExited,
+"Process should have exited.")
+self.assertTrue(
+process.GetExitStatus() == 0,
+"Process returned non-zero status. Were incorrect file descriptors 
passed?")
+
+@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376")
+@expectedFailureAll(
+oslist=['freebsd'],
+bugnumber="llvm.org/pr25624 still failing with Python 2.7.10")
+# The check for descriptor leakage needs to be implemented differently
+# here.
+@skipIfWindows
+@skipIfTargetAndroid()  # Android have some other file descriptors open by 
the shell
+@skipIfDarwinEmbedded #   # debugserver on ios 
has an extra fd open on launch
+def test_fd_leak_multitarget(self):
+self.build()
+exe = self.getBuildArtifact("a.out")
+
+target = self.dbg.CreateTarget(exe)
+breakpoint = target.BreakpointCreateBySourceRegex(
+'Set breakpoint here', lldb.SBFileSpec("main.c", False))
+

[Lldb-commits] [PATCH] D42955: Make Module::GetSectionList output consistent

[Greg Clayton via Phabricator via lldb-commits]

clayborg added inline comments.
Herald added a subscriber: arichardson.



Comment at: source/Core/Module.cpp:1286
+if (SymbolVendor *vendor = GetSymbolVendor())
+  vendor->CreateSections(*GetUnifiedSectionList());
   }

should we pass "obj_file" down into the SymbolVendor::CreateSections(...) call 
for the case where the symbol vendor is using the same ObjectFile that it can 
just return?


https://reviews.llvm.org/D42955



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

Re: [Lldb-commits] [lldb] r324743 - [Testsuite] Remove leak tests, it's not useful anymore.

[Davide Italiano via lldb-commits]

Apologies, I clearly misunderstood. I'll add this again.

On Mon, Feb 12, 2018 at 2:52 AM, Pavel Labath via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> I think you misunderstood the purpose the purpose of this test. The
> test was there to make sure that *lldb* does not leak file descriptors
> into the inferior (when I wrote it a couple of years ago, we were
> leaking about half a dozen of them). The python version check was
> added there just because we found there are some leaks coming from
> python itself that we could not control (so we skipped the test with
> those versions).
>
> With this in mind, I think the test is still very much useful. I think
> a better cleanup would be to rewrite this test to not depend on python
> so much, e.g. by driving the test from a command line lldb client a'la
> the tests in `lldb/lit/Expr` (unfortunately I can't think of a way to
> check that an FD is not leaked in a different way than with a
> full-scale integration test).
>
> On 9 February 2018 at 22:48, Vedant Kumar via lldb-commits
>  wrote:
> > Nice!
> >
> > vedant
> >
> >> On Feb 9, 2018, at 8:06 AM, Davide Italiano via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> >>
> >> Author: davide
> >> Date: Fri Feb  9 08:06:39 2018
> >> New Revision: 324743
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=324743=rev
> >> Log:
> >> [Testsuite] Remove leak tests, it's not useful anymore.
> >>
> >> This only worked on MacOS, which now ships a newer version of
> >> python without this bug. As such, we don't leak the fd, and
> >> this test is not needed anymore (as it also hardcoded the python
> >> version in the check).
> >>
> >> Removed:
> >>lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-
> leak/Makefile
> >>lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-
> leak/TestFdLeak.py
> >>lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-
> leak/main.c
> >>
> >> Removed: lldb/trunk/packages/Python/lldbsuite/test/
> functionalities/avoids-fd-leak/Makefile
> >> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/
> Python/lldbsuite/test/functionalities/avoids-fd-
> leak/Makefile?rev=324742=auto
> >> 
> ==
> >> --- lldb/trunk/packages/Python/lldbsuite/test/
> functionalities/avoids-fd-leak/Makefile (original)
> >> +++ lldb/trunk/packages/Python/lldbsuite/test/
> functionalities/avoids-fd-leak/Makefile (removed)
> >> @@ -1,5 +0,0 @@
> >> -LEVEL = ../../make
> >> -
> >> -C_SOURCES := main.c
> >> -
> >> -include $(LEVEL)/Makefile.rules
> >>
> >> Removed: lldb/trunk/packages/Python/lldbsuite/test/
> functionalities/avoids-fd-leak/TestFdLeak.py
> >> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/
> Python/lldbsuite/test/functionalities/avoids-fd-
> leak/TestFdLeak.py?rev=324742=auto
> >> 
> ==
> >> --- lldb/trunk/packages/Python/lldbsuite/test/
> functionalities/avoids-fd-leak/TestFdLeak.py (original)
> >> +++ lldb/trunk/packages/Python/lldbsuite/test/
> functionalities/avoids-fd-leak/TestFdLeak.py (removed)
> >> @@ -1,108 +0,0 @@
> >> -"""
> >> -Test whether a process started by lldb has no extra file descriptors
> open.
> >> -"""
> >> -
> >> -from __future__ import print_function
> >> -
> >> -
> >> -import os
> >> -import lldb
> >> -from lldbsuite.test import lldbutil
> >> -from lldbsuite.test.lldbtest import *
> >> -from lldbsuite.test.decorators import *
> >> -
> >> -
> >> -def python_leaky_fd_version(test):
> >> -import sys
> >> -# Python random module leaks file descriptors on some versions.
> >> -if sys.version_info >= (2, 7, 8) and sys.version_info < (2, 7, 10):
> >> -return "Python random module leaks file descriptors in this
> python version"
> >> -return None
> >> -
> >> -
> >> -class AvoidsFdLeakTestCase(TestBase):
> >> -
> >> -NO_DEBUG_INFO_TESTCASE = True
> >> -
> >> -mydir = TestBase.compute_mydir(__file__)
> >> -
> >> -@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376
> ")
> >> -@expectedFailureAll(
> >> -oslist=['freebsd'],
> >> -bugnumber="llvm.org/pr25624 still failing with Python 2.7.10")
> >> -# The check for descriptor leakage needs to be implemented
> differently
> >> -# here.
> >> -@skipIfWindows
> >> -@skipIfTargetAndroid()  # Android have some other file descriptors
> open by the shell
> >> -@skipIfDarwinEmbedded #   # debugserver
> on ios has an extra fd open on launch
> >> -def test_fd_leak_basic(self):
> >> -self.do_test([])
> >> -
> >> -@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376
> ")
> >> -@expectedFailureAll(
> >> -oslist=['freebsd'],
> >> -bugnumber="llvm.org/pr25624 still failing with Python 2.7.10")
> >> -# The check for descriptor leakage needs to be 

[Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion

[Davide Italiano via Phabricator via lldb-commits]

davide added a comment.

In https://reviews.llvm.org/D43048#1004807, @labath wrote:

> (Btw, if you're looking for things to FileCheck-ify, I think the stuff under 
> `lldb/unittests/UnwindAssembly` is a prime candidate and has a much higher 
> bang/buck ratio.)


If you have ideas on how to FileCheck'ify unwind testing, I'm all for it. This 
recently came up in a discussion where the unwinder has been pointed out as 
hard to test.
Feel free to ping me offline (or just send me a mail) and we can start thinking 
about something [and then propose upstream]


https://reviews.llvm.org/D43048



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

[Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

(Btw, if you're looking for things to FileCheck-ify, I think the stuff under 
`lldb/unittests/UnwindAssembly` is a prime candidate and has a much higher 
bang/buck ratio.)


https://reviews.llvm.org/D43048



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

[Lldb-commits] [PATCH] D43096: [lit] Update how clang and other binaries are found in per-configuration directories

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: CMakeLists.txt:73-80
+  if ("${LLDB_TEST_C_COMPILER}" STREQUAL "")
+set(LLDB_TESTING_DEFAULT_C_COMPILER ON)
+  endif()
+
+  if ("${LLDB_TEST_CXX_COMPILER}" STREQUAL "")
+set(LLDB_TESTING_DEFAULT_CXX_COMPILER ON)
+  endif()

I don't think this will work the second time you run cmake (i.e., re-run cmake 
in an already-initialized build directory) as then this would pick up the 
cached value from the previous cmake run.

I think a least magic solution would be to have a cmake option to specify 
whether you are overriding the compiler, defaulting to off (and in that case 
these cache values would be ignored).



https://reviews.llvm.org/D43096



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

Re: [Lldb-commits] [lldb] r324743 - [Testsuite] Remove leak tests, it's not useful anymore.

[Pavel Labath via lldb-commits]

I think you misunderstood the purpose the purpose of this test. The
test was there to make sure that *lldb* does not leak file descriptors
into the inferior (when I wrote it a couple of years ago, we were
leaking about half a dozen of them). The python version check was
added there just because we found there are some leaks coming from
python itself that we could not control (so we skipped the test with
those versions).

With this in mind, I think the test is still very much useful. I think
a better cleanup would be to rewrite this test to not depend on python
so much, e.g. by driving the test from a command line lldb client a'la
the tests in `lldb/lit/Expr` (unfortunately I can't think of a way to
check that an FD is not leaked in a different way than with a
full-scale integration test).

On 9 February 2018 at 22:48, Vedant Kumar via lldb-commits
 wrote:
> Nice!
>
> vedant
>
>> On Feb 9, 2018, at 8:06 AM, Davide Italiano via lldb-commits 
>>  wrote:
>>
>> Author: davide
>> Date: Fri Feb  9 08:06:39 2018
>> New Revision: 324743
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=324743=rev
>> Log:
>> [Testsuite] Remove leak tests, it's not useful anymore.
>>
>> This only worked on MacOS, which now ships a newer version of
>> python without this bug. As such, we don't leak the fd, and
>> this test is not needed anymore (as it also hardcoded the python
>> version in the check).
>>
>> Removed:
>>
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile
>>
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py
>>
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/main.c
>>
>> Removed: 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile?rev=324742=auto
>> ==
>> --- 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile
>>  (original)
>> +++ 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile
>>  (removed)
>> @@ -1,5 +0,0 @@
>> -LEVEL = ../../make
>> -
>> -C_SOURCES := main.c
>> -
>> -include $(LEVEL)/Makefile.rules
>>
>> Removed: 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py?rev=324742=auto
>> ==
>> --- 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py
>>  (original)
>> +++ 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py
>>  (removed)
>> @@ -1,108 +0,0 @@
>> -"""
>> -Test whether a process started by lldb has no extra file descriptors open.
>> -"""
>> -
>> -from __future__ import print_function
>> -
>> -
>> -import os
>> -import lldb
>> -from lldbsuite.test import lldbutil
>> -from lldbsuite.test.lldbtest import *
>> -from lldbsuite.test.decorators import *
>> -
>> -
>> -def python_leaky_fd_version(test):
>> -import sys
>> -# Python random module leaks file descriptors on some versions.
>> -if sys.version_info >= (2, 7, 8) and sys.version_info < (2, 7, 10):
>> -return "Python random module leaks file descriptors in this python 
>> version"
>> -return None
>> -
>> -
>> -class AvoidsFdLeakTestCase(TestBase):
>> -
>> -NO_DEBUG_INFO_TESTCASE = True
>> -
>> -mydir = TestBase.compute_mydir(__file__)
>> -
>> -@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376")
>> -@expectedFailureAll(
>> -oslist=['freebsd'],
>> -bugnumber="llvm.org/pr25624 still failing with Python 2.7.10")
>> -# The check for descriptor leakage needs to be implemented differently
>> -# here.
>> -@skipIfWindows
>> -@skipIfTargetAndroid()  # Android have some other file descriptors open 
>> by the shell
>> -@skipIfDarwinEmbedded #   # debugserver on ios 
>> has an extra fd open on launch
>> -def test_fd_leak_basic(self):
>> -self.do_test([])
>> -
>> -@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376")
>> -@expectedFailureAll(
>> -oslist=['freebsd'],
>> -bugnumber="llvm.org/pr25624 still failing with Python 2.7.10")
>> -# The check for descriptor leakage needs to be implemented differently
>> -# here.
>> -@skipIfWindows
>> -@skipIfTargetAndroid()  # Android have some other file descriptors open 
>> by the shell
>> -@skipIfDarwinEmbedded #   # debugserver on ios 
>> has an extra fd open on launch
>> -def test_fd_leak_log(self):
>> -self.do_test(["log enable -f '/dev/null' lldb commands"])
>> 

[Lldb-commits] [PATCH] D43099: Make LLDB's clang module cache path customizable

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

There are several components in the "command line parsing"

1. argparse: parsing a single string into the individual words (processing 
quotes, backslashes, etc.)
2. resolving the "command" part of the command line (the "frame variable" part 
of "frame variable --raw-output FOO")
3. resolving the arguments of a command (the "--raw-output FOO" part)

These parts compose quite nicely, and can be individually replaced. I'll 
briefly speak about each one :

(1) is very specific to our interactive use case (for command line utilities, 
the shell/os does the parsing for us). There also isn't anything nearly similar 
in llvm (afaik).
(2) is also quite specific to how lldb commands are structured, and there also 
isn't a suitable llvm replacement. This is the level at which the "command 
aliases" are resolved.
(3) is a fairly generic piece of functionality -- we even implement it by 
delegating to getopt (in a scarily un-thread-safe way). For this there are 
*two* competing implementations in llvm: `llvm::cl` and `llvm::opt`. Of these 
the first one is not suitable for our use case right now as it relies on global 
variables. Making it work probably would be a bit or work. However, using the 
second one should be fairly easy, and it should be generic-enough (it's the 
thing that handles crazy gcc command lines).

The reason I'm spelling it out this way is because I think you were mostly 
talking about (3), but some of the difficulties Jim pointed out (command 
aliases) just aren't relevant there.  I don't think llvm::opt handles "shortest 
match" options yet, but that should be fairly easy to add.  On the flip side, 
the library has recently gained argument suggestion capabilities (`error: 
unknown argument '-gllbb', did you mean '-glldb'`), so we would get that for 
free. Making sure tab completion works there would require a bit of thought, 
but I think this should not interfere with this library too much (after all, we 
use getopt now, and it does not support tab completion either).


Repository:
  rL LLVM

https://reviews.llvm.org/D43099



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

[Lldb-commits] [lldb] r324870 - Skip TestTargetXMLArch on non-darwin OSs

[Pavel Labath via lldb-commits]

Author: labath
Date: Mon Feb 12 01:46:06 2018
New Revision: 324870

URL: http://llvm.org/viewvc/llvm-project?rev=324870=rev
Log:
Skip TestTargetXMLArch on non-darwin OSs

This test uses XML packets, but libxml is an optional dependency of
lldb, and this test fails if it is not present.

I'm leaving this enabled on mac, as thats the only platform that's
likely to have libxml always available, but ideally we should have a way
to skip this based on build configuration. I'll see if I can whip
something like that up soon, but for the time being, this unblocks the
buildbots.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestTargetXMLArch.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestTargetXMLArch.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestTargetXMLArch.py?rev=324870=324869=324870=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestTargetXMLArch.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestTargetXMLArch.py
 Mon Feb 12 01:46:06 2018
@@ -6,6 +6,7 @@ from gdbclientutils import *
 
 class TestTargetXMLArch(GDBRemoteTestBase):
 
+@skipIf(hostoslist=no_match(lldbplatformutil.getDarwinOSTriples()))
 @expectedFailureAll(archs=["i386"])
 def test(self):
 """


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