[Lldb-commits] [PATCH] D55522: Cache memory regions in ProcessMinidump and use the linux maps as the source of the information if available.

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Looks good to me. Thanks for moving the function to a more generic place. I can 
get rid of the copy in NativeProcessLinux once this lands.




Comment at: source/Plugins/Process/Utility/LinuxProcMaps.cpp:19
+static Status
+ParseMemoryRegionInfoFromProcMapsLine(llvm::StringRef &maps_line,
+  MemoryRegionInfo &memory_region_info) {

It doesn't look like this maps_line needs to be a reference.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55522/new/

https://reviews.llvm.org/D55522



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

[Lldb-commits] [PATCH] D55582: [Reproducers] Add command reproducer

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D55582#1330715 , @JDevlieghere 
wrote:

> I played around with this today:
>
> - I'm totally convinced that we should replay by swapping out stdin with a 
> file from the reproducer. This makes this better overall.
> - I'm not convinced that capturing just stdin is an improvement. What I like 
> about the current approach is that we don't have to bother with the `-o`/`-S` 
> commands when replaying. We already have a mechanism to deal with them so I 
> don't think it's unreasonable to piggyback on it, especially because this is 
> how we display it to the user.


Hm.. so the way, I'd imagine this working is that `-o` and friends (as well as 
pretty much every other command line argument) would be captured by the SB 
recorder, once they cross the SB boundary. For the `-o` commands that would be 
the moment the driver calls `m_debugger.SetInputFileHandle` 
https://github.com/llvm-mirror/lldb/blob/master/tools/driver/Driver.cpp#L697 , 
followed by `m_debugger.RunCommandInterpreter` a couple of lines lower. So, the 
SB recorder would notice that we're changing what the debugger considers as 
it's `stdin`, and direct the "stdin" recorder (or create a new instance of it, 
or whatever), to capture it.

Then, during replay, the SB replayer would notice that the driver called 
`SBDebugger::SetInputFileHandle`, so it would create a fake `FILE*` object (or 
maybe just open the file containing the captured commands from the disk?), and 
pass *that* as the stdin handle. Then it could just call 
`SBDebugger::RunCommandInterperer` the same way as the driver did. And I am 
hoping that pretty much everything below `RunCommandInterpreter` could run 
oblivious to the fact that replay is taking place.

> On the other hand, I generally try to keep the code path the same between the 
> regular and reproducer case, and processing the command line options in the 
> reproducer case would reuse more of the existing code.

In this (imaginary) world, the recording/replay would only deal with the things 
that happen below the SB API. Anything that happens above it could only be 
glimpsed through it's effects on the SB. So, when initializing replay, as soon 
the driver notices the `--replay` argument it would just load that file, call 
`RunReplay` and be done. There wouldn't be a need for any 
`command-line-argument` recorder, or making sure the command line arguments 
match in some other way.

> Finally, we'd have to figure out a way to test this, because currently we 
> rely on the commands provided/sourced through the command line to test the 
> replay. How would we test this functionality when only capturing from stdin?

By "capturing stdin" I meant capturing anything which the 
`RunCommandInterpreter` considers as it's "stdin", i.e., everything where the 
debugger gets its commands from.

So, if we assume everything I said above is true, then capturing the command 
stream produced by processing the command-line arguments should work the same 
way as capturing the commands given interactively. So, perhaps the first step 
would be to make sure you can capture the commands issued via command-line 
args. This should be easily testable via something like:

  RUN: %lldb --record %t -b -o cmd1 -o cmd2 -O cmd3 ...
  RUN: %lldb --replay %t | FileCheck %s
  CHECK: make sure cmd1, cmd2, cmd3 got executed

Of course, capturing *real* stdin will come with additional challenges, both 
for recording and testing. For recording, we'll have to decide whether to try 
to capture raw stdin with enough fidelity so libedit can be driven through it, 
or we go one level higher, and try to capture the "cooked" command stream 
coming out of libedit. The testing strategy will depend on decision made here. 
In case we capture cooked commands, the situation should be very similar to 
command line options, so it might be enough to test by just passing the 
commands to the driver via stdin (`%lldb <%t/my_commands.txt`)  instead of via 
command line args. In case of low-level recordings, we may need to test using 
something which can provide a realistic-looking fake terminal such as pexpect 
(yikes). But even in that case, that should be only necessary to test the 
handling of funny line-editing operations (such as backspaces, cursor keys, 
etc.), and for general functionality redirecting stdin from file should be 
enough.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55582/new/

https://reviews.llvm.org/D55582



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

Re: [Lldb-commits] [PATCH] D55142: Minidump debugging using the native PDB reader

[Pavel Labath via lldb-commits]

On 13/12/2018 23:19, Zachary Turner wrote:
The permanent solution would be figuring out what to do about the 
ObjectFile situation (e.g. do we want to make an ObjectFilePDB or do we 
want to live in a world where SymbolFiles need not be backed by 
ObjectFiles?), and then regardless of what we decide there, implementing 
the SymbolVendor that can search a combination of locations including 
(but not limited to) a symbol server.  lldb already has the notion of a 
symbol path.  So using this we could just use that existing logic to 
search the symbol path, and before you run LLDB make sure your minidump 
.pdb files are in that search path.  If we make an ObjectFilePDB, then 
this should be able to fall out naturally of the existing design with no 
additional work, because it will use the normal SymbolVendor search 
logic.  If we allow SymbolFilePDB to live without an ObjectFilePDB, then 
we would have to make changes similar to what you proposed earlier where 
we can still get a SymbolVendor and use it to execute its default search 
algorithm, plus probably some other changes to make sure various other 
things work correctly in the presence of ObjectFile-less SymbolFiles.




+1 for that.


I'm particularly interested in the result of this, as I'm in the middle 
of adding ObjectFileBreakpad, whose raison d´être is to make things 
interoperate more nicely with the rest of lldb.


My take on this is that going the ObjectFile route is going to be faster 
and less intrusive, but it may produce some odd-looking APIs. E.g. maybe 
the ObjectFilePDB will claim it contains no sections (which is the 
traditional way of passing information from ObjectFiles to SymbolFiles), 
but instead provide some private API to access the underlying llvm data 
structures, which will be used by SymbolFilePDB to do it's thing.


OTOH, object-less symbol files has the potential to produce 
nicer-looking APIs overall, but it will require a lot of changes to core 
lldb to make it happen. E.g., besides the fact that searching for 
"symbols" happens on the object file level (which is the whole reason 
we're having this discussion), the object files are also responsible for 
providing unwind information. That would have to change too.

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

[Lldb-commits] [lldb] r349149 - Mark Permissions as a bitmask enum

[Pavel Labath via lldb-commits]

Author: labath
Date: Fri Dec 14 05:51:20 2018
New Revision: 349149

URL: http://llvm.org/viewvc/llvm-project?rev=349149&view=rev
Log:
Mark Permissions as a bitmask enum

this allows one to use bitwise operators on the variables of this type
without complicated casting.

The gotcha here is that the combinations of these enums were being used
in some constexpr contexts such as case labels (case
ePermissionsWritable | ePermissionsExecutable:), which is not possible
if the user-defined operator| is not constexpr.

So, this commit also marks these operators as constexpr. I am committing
this as a small standalone patch so it can be easily reverted if some
compiler has an issue with this.

Modified:
lldb/trunk/include/lldb/lldb-enumerations.h

Modified: lldb/trunk/include/lldb/lldb-enumerations.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/lldb-enumerations.h?rev=349149&r1=349148&r2=349149&view=diff
==
--- lldb/trunk/include/lldb/lldb-enumerations.h (original)
+++ lldb/trunk/include/lldb/lldb-enumerations.h Fri Dec 14 05:51:20 2018
@@ -17,17 +17,17 @@
 // you mark Enum with LLDB_MARK_AS_BITMASK_ENUM(Enum), however, you can simply
 // write Enum a = eFoo | eBar.
 #define LLDB_MARK_AS_BITMASK_ENUM(Enum)
\
-  inline Enum operator|(Enum a, Enum b) {  
\
+  constexpr Enum operator|(Enum a, Enum b) {   
\
 return static_cast(  
\
 static_cast::type>(a) | 
\
 static_cast::type>(b)); 
\
   }
\
-  inline Enum operator&(Enum a, Enum b) {  
\
+  constexpr Enum operator&(Enum a, Enum b) {   
\
 return static_cast(  
\
 static_cast::type>(a) & 
\
 static_cast::type>(b)); 
\
   }
\
-  inline Enum operator~(Enum a) {  
\
+  constexpr Enum operator~(Enum a) {   
\
 return static_cast(  
\
 ~static_cast::type>(a));
\
   }
\
@@ -395,6 +395,7 @@ LLDB_MARK_AS_BITMASK_ENUM(SymbolContextI
 FLAGS_ENUM(Permissions){ePermissionsWritable = (1u << 0),
 ePermissionsReadable = (1u << 1),
 ePermissionsExecutable = (1u << 2)};
+LLDB_MARK_AS_BITMASK_ENUM(Permissions)
 
 enum InputReaderAction {
   eInputReaderActivate, // reader is newly pushed onto the reader stack


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

[Lldb-commits] [lldb] r349153 - Fix build with older (<3.0) swigs

[Pavel Labath via lldb-commits]

Author: labath
Date: Fri Dec 14 06:25:20 2018
New Revision: 349153

URL: http://llvm.org/viewvc/llvm-project?rev=349153&view=rev
Log:
Fix build with older (<3.0) swigs

It turns out it wasn't the compilers, but swig who had issues with my
previous patch -- older versions do not recognise the "constexpr"
keyword.

Fortunately, that can be fixed the same way we fix all other swig
incompatibilities: #ifndef SWIG.

Modified:
lldb/trunk/include/lldb/lldb-enumerations.h

Modified: lldb/trunk/include/lldb/lldb-enumerations.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/lldb-enumerations.h?rev=349153&r1=349152&r2=349153&view=diff
==
--- lldb/trunk/include/lldb/lldb-enumerations.h (original)
+++ lldb/trunk/include/lldb/lldb-enumerations.h Fri Dec 14 06:25:20 2018
@@ -12,10 +12,13 @@
 
 #include 
 
+#ifndef SWIG
 // Macro to enable bitmask operations on an enum.  Without this, Enum | Enum
 // gets promoted to an int, so you have to say Enum a = Enum(eFoo | eBar).  If
 // you mark Enum with LLDB_MARK_AS_BITMASK_ENUM(Enum), however, you can simply
 // write Enum a = eFoo | eBar.
+// Unfortunately, swig<3.0 doesn't recognise the constexpr keyword, so remove
+// this entire block, as it is not necessary for swig processing.
 #define LLDB_MARK_AS_BITMASK_ENUM(Enum)
\
   constexpr Enum operator|(Enum a, Enum b) {   
\
 return static_cast(  
\
@@ -39,6 +42,9 @@
 a = a & b; 
\
 return a;  
\
   }
+#else
+#define LLDB_MARK_AS_BITMASK_ENUM(Enum)
+#endif
 
 #ifndef SWIG
 // With MSVC, the default type of an enum is always signed, even if one of the


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

[Lldb-commits] [lldb] r349154 - Fix minidump unit test failures from r349062

[Pavel Labath via lldb-commits]

Author: labath
Date: Fri Dec 14 06:41:04 2018
New Revision: 349154

URL: http://llvm.org/viewvc/llvm-project?rev=349154&view=rev
Log:
Fix minidump unit test failures from r349062

This commit added new test inputs, but it did not add them to the cmake
files. This caused the test to fail at runtime.

While in there, I also sorted the list of minidump test inputs.

Modified:
lldb/trunk/unittests/Process/minidump/CMakeLists.txt

Modified: lldb/trunk/unittests/Process/minidump/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Process/minidump/CMakeLists.txt?rev=349154&r1=349153&r2=349154&view=diff
==
--- lldb/trunk/unittests/Process/minidump/CMakeLists.txt (original)
+++ lldb/trunk/unittests/Process/minidump/CMakeLists.txt Fri Dec 14 06:41:04 
2018
@@ -13,18 +13,21 @@ add_lldb_unittest(LLDBMinidumpTests
   )
 
 set(test_inputs
+   bad_duplicate_streams.dmp
+   bad_overlapping_streams.dmp
+   fizzbuzz_no_heap.dmp
+   fizzbuzz_wow64.dmp
linux-i386.dmp
linux-x86_64.dmp
linux-x86_64_not_crashed.dmp
-   fizzbuzz_no_heap.dmp
-   fizzbuzz_wow64.dmp
-   bad_duplicate_streams.dmp
-   bad_overlapping_streams.dmp
-   thread-list-padded.dmp
-   thread-list-not-padded.dmp
-   module-list-padded.dmp
-   module-list-not-padded.dmp
+   memory-list-not-padded.dmp
memory-list-padded.dmp
-   memory-list-not-padded.dmp)
+   module-list-not-padded.dmp
+   module-list-padded.dmp
+   modules-dup-min-addr.dmp
+   modules-order.dmp
+   thread-list-not-padded.dmp
+   thread-list-padded.dmp
+   )
 
 add_unittest_inputs(LLDBMinidumpTests "${test_inputs}")


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

[Lldb-commits] [PATCH] D55706: ELF: more section creation cleanup

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: clayborg, krytarowski.
Herald added subscribers: arichardson, emaste.
Herald added a reviewer: espindola.

This patch attempts to move as much code as possible out of the
CreateSections function to make room for future improvements there. Some
of this may be slightly over-engineered (VMAddressProvider), but I
wanted to keep the logic of this function very simple, because once I
start taking segment headers into acount (as discussed in D55356 
), the
function is going to grow significantly.

While in there, I also added tests for various bits of functionality.

This should be NFC, except that I changed the order of hac^H^Heuristicks
for determining section type slightly. Previously, name-based deduction
(.symtab -> symtab) would take precedence over type-based (SHT_SYMTAB ->
symtab) one. In fact we would assert if we ran into a .text section with
type SHT_SYMTAB. Though unlikely to matter in practice, this order
seemed wrong to me, so I have inverted it.


https://reviews.llvm.org/D55706

Files:
  lit/Modules/ELF/compressed-sections.yaml
  lit/Modules/ELF/section-addresses.yaml
  lit/Modules/ELF/section-permissions.yaml
  lit/Modules/ELF/section-types-edgecases.yaml
  lit/Modules/ELF/section-types.yaml
  lit/Modules/MachO/subsections.yaml
  source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  source/Plugins/ObjectFile/ELF/ObjectFileELF.h
  tools/lldb-test/lldb-test.cpp

Index: tools/lldb-test/lldb-test.cpp
===
--- tools/lldb-test/lldb-test.cpp
+++ tools/lldb-test/lldb-test.cpp
@@ -30,6 +30,7 @@
 #include "lldb/Target/Target.h"
 #include "lldb/Utility/CleanUp.h"
 #include "lldb/Utility/DataExtractor.h"
+#include "lldb/Utility/State.h"
 #include "lldb/Utility/StreamString.h"
 
 #include "llvm/ADT/IntervalMap.h"
@@ -733,7 +734,9 @@
 Printer.formatLine("Index: {0}", I);
 Printer.formatLine("Name: {0}", S->GetName().GetStringRef());
 Printer.formatLine("Type: {0}", S->GetTypeAsCString());
+Printer.formatLine("Permissions: {0}", GetPermissionsAsCString(S->GetPermissions()));
 Printer.formatLine("Thread specific: {0:y}", S->IsThreadSpecific());
+Printer.formatLine("VM address: {0:x}", S->GetFileAddress());
 Printer.formatLine("VM size: {0}", S->GetByteSize());
 Printer.formatLine("File size: {0}", S->GetFileSize());
 
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.h
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.h
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.h
@@ -246,6 +246,8 @@
   /// Returns the number of headers parsed.
   size_t ParseSectionHeaders();
 
+  lldb::SectionType GetSectionType(const ELFSectionHeaderInfo &H) const;
+
   static void ParseARMAttributes(lldb_private::DataExtractor &data,
  uint64_t length,
  lldb_private::ArchSpec &arch_spec);
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1735,7 +1735,7 @@
   return 0;
 }
 
-static SectionType getSectionType(llvm::StringRef Name) {
+static SectionType GetSectionTypeFromName(llvm::StringRef Name) {
   return llvm::StringSwitch(Name)
   .Case(".ARM.exidx", eSectionTypeARMexidx)
   .Case(".ARM.extab", eSectionTypeARMextab)
@@ -1774,16 +1774,85 @@
   .Default(eSectionTypeOther);
 }
 
+SectionType ObjectFileELF::GetSectionType(const ELFSectionHeaderInfo &H) const {
+  switch (H.sh_type) {
+  case SHT_PROGBITS:
+if (H.sh_flags & SHF_EXECINSTR)
+  return eSectionTypeCode;
+break;
+  case SHT_SYMTAB:
+return eSectionTypeELFSymbolTable;
+  case SHT_DYNSYM:
+return eSectionTypeELFDynamicSymbols;
+  case SHT_RELA:
+  case SHT_REL:
+return eSectionTypeELFRelocationEntries;
+  case SHT_DYNAMIC:
+return eSectionTypeELFDynamicLinkInfo;
+  }
+  SectionType Type = GetSectionTypeFromName(H.section_name.GetStringRef());
+  if (Type == eSectionTypeOther) {
+// the kalimba toolchain assumes that ELF section names are free-form.
+// It does support linkscripts which (can) give rise to various
+// arbitrarily named sections being "Code" or "Data".
+Type = kalimbaSectionType(m_header, H);
+  }
+  return Type;
+}
+
+static uint32_t GetTargetByteSize(SectionType Type, const ArchSpec &arch) {
+  switch (Type) {
+  case eSectionTypeData:
+  case eSectionTypeZeroFill:
+return arch.GetDataByteSize();
+  case eSectionTypeCode:
+return arch.GetCodeByteSize();
+  default:
+return 1;
+  }
+}
+
+static Permissions GetPermissions(const ELFSectionHeader &H) {
+  Permissions Perm = Permissions(0);
+  if (H.sh_flags & SHF_ALLOC)
+Perm |= ePermissionsReadable;
+  if (H.sh_flags & SHF_WRITE)
+Perm |= ePermissionsWritable;

[Lldb-commits] [PATCH] D55706: ELF: more section creation cleanup

[Kamil Rytarowski via Phabricator via lldb-commits]

krytarowski edited reviewers, added: joerg; removed: krytarowski.
krytarowski added a comment.

I recommend joerg@ as a reviewer for ELF specifics.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55706/new/

https://reviews.llvm.org/D55706



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

[Lldb-commits] [PATCH] D55582: [Reproducers] Add command reproducer

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

In D55582#1331145 , @labath wrote:

> Hm.. so the way, I'd imagine this working is that `-o` and friends (as well 
> as pretty much every other command line argument) would be captured by the SB 
> recorder, once they cross the SB boundary. For the `-o` commands that would 
> be the moment the driver calls `m_debugger.SetInputFileHandle` 
> https://github.com/llvm-mirror/lldb/blob/master/tools/driver/Driver.cpp#L697 
> , followed by `m_debugger.RunCommandInterpreter` a couple of lines lower. So, 
> the SB recorder would notice that we're changing what the debugger considers 
> as it's `stdin`, and direct the "stdin" recorder (or create a new instance of 
> it, or whatever), to capture it.
>
> Then, during replay, the SB replayer would notice that the driver called 
> `SBDebugger::SetInputFileHandle`, so it would create a fake `FILE*` object 
> (or maybe just open the file containing the captured commands from the 
> disk?), and pass *that* as the stdin handle. Then it could just call 
> `SBDebugger::RunCommandInterperer` the same way as the driver did. And I am 
> hoping that pretty much everything below `RunCommandInterpreter` could run 
> oblivious to the fact that replay is taking place.


Yes, this is how SB record/replay will work. I don't disagree with this
approach, it's just that, as I said in my earlier reply, I was hoping to get
the driver working without the need for the SB reproducers. Maybe I should give
up on that?

> In this (imaginary) world, the recording/replay would only deal with the 
> things that happen below the SB API. Anything that happens above it could 
> only be glimpsed through it's effects on the SB. So, when initializing 
> replay, as soon the driver notices the `--replay` argument it would just load 
> that file, call `RunReplay` and be done. There wouldn't be a need for any 
> `command-line-argument` recorder, or making sure the command line arguments 
> match in some other way.
> 
> By "capturing stdin" I meant capturing anything which the 
> `RunCommandInterpreter` considers as it's "stdin", i.e., everything where the 
> debugger gets its commands from.

This is the tricky part though. Where and how are you going to do this? In my
opinion this shouldn't be the responsibility of the SB recorder. The latter
should be concerned with "serializing" and "deserializing" its input and
tracking what SB layer calls are being made. It should be relatively agnostic
of what the debugger does with that at a lower level.

The `FILE*` is particularly annoying. For the sake of argument let's say that
"serializing" a `FILE*` means writing its content to the reproducer, how would
we accomplish this? Maybe there's an API I don't know about, but wouldn't we
have to do this at the `fgets` level? For the command interpreter this is
either in libedit or in the IO handler (depending on the fidelity you touched
on below).

> So, if we assume everything I said above is true, then capturing the command 
> stream produced by processing the command-line arguments should work the same 
> way as capturing the commands given interactively. So, perhaps the first step 
> would be to make sure you can capture the commands issued via command-line 
> args. This should be easily testable via something like:
> 
>   RUN: %lldb --record %t -b -o cmd1 -o cmd2 -O cmd3 ...
>   RUN: %lldb --replay %t | FileCheck %s
>   CHECK: make sure cmd1, cmd2, cmd3 got executed
> 
> 
> Of course, capturing *real* stdin will come with additional challenges, both 
> for recording and testing. For recording, we'll have to decide whether to try 
> to capture raw stdin with enough fidelity so libedit can be driven through 
> it, or we go one level higher, and try to capture the "cooked" command stream 
> coming out of libedit. The testing strategy will depend on decision made 
> here. In case we capture cooked commands, the situation should be very 
> similar to command line options, so it might be enough to test by just 
> passing the commands to the driver via stdin (`%lldb <%t/my_commands.txt`)  
> instead of via command line args. In case of low-level recordings, we may 
> need to test using something which can provide a realistic-looking fake 
> terminal such as pexpect (yikes). But even in that case, that should be only 
> necessary to test the handling of funny line-editing operations (such as 
> backspaces, cursor keys, etc.), and for general functionality redirecting 
> stdin from file should be enough.

I don't think we really differentiate between *real* stdin and a file. Even
when sourcing a file go through the IOHandler, so that should be pretty
transparent, unless you actually want to differentiate which, if I understand
correctly, wouldn't be needed with your proposed approach?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55582/new/

https://reviews.llvm.org/D55582



___
lldb-commits mailing li

[Lldb-commits] [PATCH] D55582: [Reproducers] Add command reproducer

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D55582#1331333 , @JDevlieghere 
wrote:

> Yes, this is how SB record/replay will work. I don't disagree with this
>  approach, it's just that, as I said in my earlier reply, I was hoping to get
>  the driver working without the need for the SB reproducers. Maybe I should 
> give
>  up on that?


Hm... I don't know.. as this patch shows, it seems it is possible to get some 
results without the SB reproducers. My fear is that this will produce a 
solution which is very specialized to this particular use case, and which will 
have to be redone once you want more functionality out of it. Maybe that 
doesn't matter? I'm not sure..

> 
> 
>> In this (imaginary) world, the recording/replay would only deal with the 
>> things that happen below the SB API. Anything that happens above it could 
>> only be glimpsed through it's effects on the SB. So, when initializing 
>> replay, as soon the driver notices the `--replay` argument it would just 
>> load that file, call `RunReplay` and be done. There wouldn't be a need for 
>> any `command-line-argument` recorder, or making sure the command line 
>> arguments match in some other way.
>> 
>> By "capturing stdin" I meant capturing anything which the 
>> `RunCommandInterpreter` considers as it's "stdin", i.e., everything where 
>> the debugger gets its commands from.
> 
> This is the tricky part though. Where and how are you going to do this? In my
>  opinion this shouldn't be the responsibility of the SB recorder. The latter
>  should be concerned with "serializing" and "deserializing" its input and
>  tracking what SB layer calls are being made. It should be relatively agnostic
>  of what the debugger does with that at a lower level.
> 
> The `FILE*` is particularly annoying. For the sake of argument let's say that
>  "serializing" a `FILE*` means writing its content to the reproducer, how 
> would
>  we accomplish this? Maybe there's an API I don't know about, but wouldn't we
>  have to do this at the `fgets` level? For the command interpreter this is
>  either in libedit or in the IO handler (depending on the fidelity you touched
>  on below).

Yes, the FILE* is quite tricky, and it might be the trickiest part of capturing 
the SB interface. I would actually argue that capturing this *is* in the scope 
of the SB recorder, which I would define as capturing the data that flows 
across the SB boundary. For a FILE*, that obviously doesn't mean the pointer 
value, because that's going to be meaningless in subsequent runs. It has do do 
a "deep" capture of the FILE* so that it can later be recreated with reasonable 
fidelity.

In an ideal world, it would just take a snapshot of the file, and then move on, 
but that is of course not possible, because the FILE* may be a stream, and it 
would have to look into the future to capture it instantaneously. So, it will 
have to capture it incrementally, as it is being read. Which will require some 
cooperation from the lower layers of the debugger.

I'd imagine this could be done by adding a level of indirection, similar to how 
you've made all filesystem accesses go through the FileSystem class. Instead of 
FILE*. everything would deal with some proxy class, which would record it's 
interaction into the log in record mode and replay it from saved data in replay 
mode. Most of the code would still be oblivious to the fact that anything funny 
is going on, but it would have to be changed to deal with the proxy class 
instead of the raw APIs.

>> Of course, capturing *real* stdin will come with additional challenges, both 
>> for recording and testing. For recording, we'll have to decide whether to 
>> try to capture raw stdin with enough fidelity so libedit can be driven 
>> through it, or we go one level higher, and try to capture the "cooked" 
>> command stream coming out of libedit. The testing strategy will depend on 
>> decision made here. In case we capture cooked commands, the situation should 
>> be very similar to command line options, so it might be enough to test by 
>> just passing the commands to the driver via stdin (`%lldb 
>> <%t/my_commands.txt`)  instead of via command line args. In case of 
>> low-level recordings, we may need to test using something which can provide 
>> a realistic-looking fake terminal such as pexpect (yikes). But even in that 
>> case, that should be only necessary to test the handling of funny 
>> line-editing operations (such as backspaces, cursor keys, etc.), and for 
>> general functionality redirecting stdin from file should be enough.
> 
> I don't think we really differentiate between *real* stdin and a file. Even
>  when sourcing a file go through the IOHandler, so that should be pretty
>  transparent, unless you actually want to differentiate which, if I understand
>  correctly, wouldn't be needed with your proposed approach?

I am afraid you lost me there. I am not sure what you wanted to say, but yes, I 
am saying th

[Lldb-commits] [PATCH] D55575: [NativePDB] Support local variables

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

local-variables.cpp is failing on the Buildbot:

http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/2255/steps/test/logs/stdio


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55575/new/

https://reviews.llvm.org/D55575



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

Re: [Lldb-commits] [PATCH] D55575: [NativePDB] Support local variables

[Zachary Turner via lldb-commits]

I can't access the buildbot right now, it's just timing out and never
loading the webpage.  If you have it open and can paste the output here I
can try to figure out what's wrong, otherwise I'll have to wait for it to
become available again.

On Fri, Dec 14, 2018 at 10:31 AM Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> wrote:

> stella.stamenova added a comment.
>
> local-variables.cpp is failing on the Buildbot:
>
>
> http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/2255/steps/test/logs/stdio
>
>
> Repository:
>   rLLDB LLDB
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D55575/new/
>
> https://reviews.llvm.org/D55575
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D55575: [NativePDB] Support local variables

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

  $ ":" "RUN: at line 5"
  $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\lldb.EXE" "-S" 
"E:/build_slave/lldb-x64-windows-ninja/llvm/tools/lldb/lit\lit-lldb-init" "-f" 
"E:\build_slave\lldb-x64-windows-ninja\build\tools\lldb\lit\SymbolFile\NativePDB\Output\local-variables.cpp.tmp.exe"
 "-s" 
"E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB/Inputs/local-variables.lldbinit"
  $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\FileCheck.EXE" 
"E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp"
  # command stderr:
  
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp:154:16:
 error: CHECK-NEXT: expected string not found in input
  
  // CHECK-NEXT: Dumping clang ast for 7 modules.
  
 ^
  
  :140:1: note: scanning from here
  
  Dumping clang ast for 8 modules.
  
  ^
  
  
  error: command failed with exit status: 1


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55575/new/

https://reviews.llvm.org/D55575



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

Re: [Lldb-commits] [PATCH] D55575: [NativePDB] Support local variables

[Zachary Turner via lldb-commits]

Ahh, that seems easy enough to fix.  Just need to change the 7 to a
{{.*}}.  Since we're actually compiling and running a process on the
buildbot, different versions of Windows will affect this.

On Fri, Dec 14, 2018 at 10:39 AM Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> wrote:

> stella.stamenova added a comment.
>
>   $ ":" "RUN: at line 5"
>   $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\lldb.EXE" "-S"
> "E:/build_slave/lldb-x64-windows-ninja/llvm/tools/lldb/lit\lit-lldb-init"
> "-f"
> "E:\build_slave\lldb-x64-windows-ninja\build\tools\lldb\lit\SymbolFile\NativePDB\Output\local-variables.cpp.tmp.exe"
> "-s"
> "E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB/Inputs/local-variables.lldbinit"
>   $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\FileCheck.EXE"
> "E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp"
>   # command stderr:
>
> E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp:154:16:
> error: CHECK-NEXT: expected string not found in input
>
>   // CHECK-NEXT: Dumping clang ast for 7 modules.
>
>  ^
>
>   :140:1: note: scanning from here
>
>   Dumping clang ast for 8 modules.
>
>   ^
>
>
>   error: command failed with exit status: 1
>
>
> Repository:
>   rLLDB LLDB
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D55575/new/
>
> https://reviews.llvm.org/D55575
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D55706: ELF: more section creation cleanup

[Greg Clayton via Phabricator via lldb-commits]

clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.

Looks good.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55706/new/

https://reviews.llvm.org/D55706



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

[Lldb-commits] [lldb] r349175 - [NativePDB] Fix local-variables.cpp test.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Fri Dec 14 10:43:42 2018
New Revision: 349175

URL: http://llvm.org/viewvc/llvm-project?rev=349175&view=rev
Log:
[NativePDB] Fix local-variables.cpp test.

Since we're actually running an executable on the host now, different
versions of Windows could load different system libraries, so we need
to regex out the number of loaded modules.

Modified:
lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp

Modified: lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp?rev=349175&r1=349174&r2=349175&view=diff
==
--- lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp (original)
+++ lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp Fri Dec 14 10:43:42 
2018
@@ -151,7 +151,7 @@ int main(int argc, char **argv) {
 // CHECK-NEXT: Process {{.*}} exited with status = 18 (0x0012)
 
 // CHECK:  (lldb) target modules dump ast
-// CHECK-NEXT: Dumping clang ast for 7 modules.
+// CHECK-NEXT: Dumping clang ast for {{.*}} modules.
 // CHECK-NEXT: TranslationUnitDecl
 // CHECK-NEXT: |-FunctionDecl {{.*}} main 'int (int, char **)'
 // CHECK-NEXT: | |-ParmVarDecl {{.*}} argc 'int'


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

Re: [Lldb-commits] [lldb] r349175 - [NativePDB] Fix local-variables.cpp test.

[Pavel Labath via lldb-commits]

On 14/12/2018 19:43, Zachary Turner via lldb-commits wrote:

Author: zturner
Date: Fri Dec 14 10:43:42 2018
New Revision: 349175

URL: http://llvm.org/viewvc/llvm-project?rev=349175&view=rev
Log:
[NativePDB] Fix local-variables.cpp test.

Since we're actually running an executable on the host now, different
versions of Windows could load different system libraries, so we need
to regex out the number of loaded modules.

Modified:
 lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp

Modified: lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp?rev=349175&r1=349174&r2=349175&view=diff
==
--- lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp (original)
+++ lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp Fri Dec 14 10:43:42 
2018
@@ -151,7 +151,7 @@ int main(int argc, char **argv) {
  // CHECK-NEXT: Process {{.*}} exited with status = 18 (0x0012)
  
  // CHECK:  (lldb) target modules dump ast

-// CHECK-NEXT: Dumping clang ast for 7 modules.
+// CHECK-NEXT: Dumping clang ast for {{.*}} modules.
  // CHECK-NEXT: TranslationUnitDecl
  // CHECK-NEXT: |-FunctionDecl {{.*}} main 'int (int, char **)'
  // CHECK-NEXT: | |-ParmVarDecl {{.*}} argc 'int'


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



It looks like it would be nice to be able to specify the module whose 
clang ast one wishes to dump. This would reduce the amount of output, 
and with it, the chance of FileCheck picking up some false positives.

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

Re: [Lldb-commits] [lldb] r349175 - [NativePDB] Fix local-variables.cpp test.

[Zachary Turner via lldb-commits]

I don't know if there's a good way to do that.  Because debuggers need to
be able to see across multiple translation units, this is implemented
internally as constructing one giant AST that contains everything for the
entire program.  LLDB has no notion of a per-module AST, so it would be
hard to make this work.


On Fri, Dec 14, 2018 at 10:51 AM Pavel Labath  wrote:

> On 14/12/2018 19:43, Zachary Turner via lldb-commits wrote:
> > Author: zturner
> > Date: Fri Dec 14 10:43:42 2018
> > New Revision: 349175
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=349175&view=rev
> > Log:
> > [NativePDB] Fix local-variables.cpp test.
> >
> > Since we're actually running an executable on the host now, different
> > versions of Windows could load different system libraries, so we need
> > to regex out the number of loaded modules.
> >
> > Modified:
> >  lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp
> >
> > Modified: lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp?rev=349175&r1=349174&r2=349175&view=diff
> >
> ==
> > --- lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp (original)
> > +++ lldb/trunk/lit/SymbolFile/NativePDB/local-variables.cpp Fri Dec 14
> 10:43:42 2018
> > @@ -151,7 +151,7 @@ int main(int argc, char **argv) {
> >   // CHECK-NEXT: Process {{.*}} exited with status = 18 (0x0012)
> >
> >   // CHECK:  (lldb) target modules dump ast
> > -// CHECK-NEXT: Dumping clang ast for 7 modules.
> > +// CHECK-NEXT: Dumping clang ast for {{.*}} modules.
> >   // CHECK-NEXT: TranslationUnitDecl
> >   // CHECK-NEXT: |-FunctionDecl {{.*}} main 'int (int, char **)'
> >   // CHECK-NEXT: | |-ParmVarDecl {{.*}} argc 'int'
> >
> >
> > ___
> > lldb-commits mailing list
> > lldb-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> >
>
> It looks like it would be nice to be able to specify the module whose
> clang ast one wishes to dump. This would reduce the amount of output,
> and with it, the chance of FileCheck picking up some false positives.
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D55575: [NativePDB] Support local variables

[Zachary Turner via lldb-commits]

I've fixed it.  It looks like the bot should be green again once this test
starts passing.  Can you make it noisy and starting to send emails now?

On Fri, Dec 14, 2018 at 10:42 AM Zachary Turner  wrote:

> Ahh, that seems easy enough to fix.  Just need to change the 7 to a
> {{.*}}.  Since we're actually compiling and running a process on the
> buildbot, different versions of Windows will affect this.
>
> On Fri, Dec 14, 2018 at 10:39 AM Stella Stamenova via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> stella.stamenova added a comment.
>>
>>   $ ":" "RUN: at line 5"
>>   $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\lldb.EXE" "-S"
>> "E:/build_slave/lldb-x64-windows-ninja/llvm/tools/lldb/lit\lit-lldb-init"
>> "-f"
>> "E:\build_slave\lldb-x64-windows-ninja\build\tools\lldb\lit\SymbolFile\NativePDB\Output\local-variables.cpp.tmp.exe"
>> "-s"
>> "E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB/Inputs/local-variables.lldbinit"
>>   $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\FileCheck.EXE"
>> "E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp"
>>   # command stderr:
>>
>> E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp:154:16:
>> error: CHECK-NEXT: expected string not found in input
>>
>>   // CHECK-NEXT: Dumping clang ast for 7 modules.
>>
>>  ^
>>
>>   :140:1: note: scanning from here
>>
>>   Dumping clang ast for 8 modules.
>>
>>   ^
>>
>>
>>   error: command failed with exit status: 1
>>
>>
>> Repository:
>>   rLLDB LLDB
>>
>> CHANGES SINCE LAST ACTION
>>   https://reviews.llvm.org/D55575/new/
>>
>> https://reviews.llvm.org/D55575
>>
>>
>>
>>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D55575: [NativePDB] Support local variables

[Stella Stamenova via lldb-commits]

It’s actually not green – the unexpected passes are counted as a failure. With 
Pavel’s change to add the gcc builder, most of those can now be enabled, so I 
am going to do that today, but there’s still a couple that are “unexpectedly 
passing” when they are in fact failing. We’ll need to fix that before making it 
noisy.

From: Zachary Turner 
Sent: Friday, December 14, 2018 10:53 AM
To: reviews+d55575+public+5ea6161324294...@reviews.llvm.org
Cc: pa...@labath.sk; mose...@google.com; aleksandr.ura...@jetbrains.com; 
amcca...@google.com; clayb...@gmail.com; leonid.mashins...@jetbrains.com; 
Stella Stamenova ; abidh@gmail.com; 
teempe...@gmail.com; apra...@apple.com; jdevliegh...@apple.com; 
lldb-commits@lists.llvm.org; l...@inglorion.net
Subject: Re: [PATCH] D55575: [NativePDB] Support local variables

I've fixed it.  It looks like the bot should be green again once this test 
starts passing.  Can you make it noisy and starting to send emails now?

On Fri, Dec 14, 2018 at 10:42 AM Zachary Turner 
mailto:ztur...@google.com>> wrote:
Ahh, that seems easy enough to fix.  Just need to change the 7 to a {{.*}}.  
Since we're actually compiling and running a process on the buildbot, different 
versions of Windows will affect this.

On Fri, Dec 14, 2018 at 10:39 AM Stella Stamenova via Phabricator 
mailto:revi...@reviews.llvm.org>> wrote:
stella.stamenova added a comment.

  $ ":" "RUN: at line 5"
  $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\lldb.EXE" "-S" 
"E:/build_slave/lldb-x64-windows-ninja/llvm/tools/lldb/lit\lit-lldb-init" "-f" 
"E:\build_slave\lldb-x64-windows-ninja\build\tools\lldb\lit\SymbolFile\NativePDB\Output\local-variables.cpp.tmp.exe"
 "-s" 
"E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB/Inputs/local-variables.lldbinit"
  $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\FileCheck.EXE" 
"E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp"
  # command stderr:
  
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp:154:16:
 error: CHECK-NEXT: expected string not found in input

  // CHECK-NEXT: Dumping clang ast for 7 modules.

 ^

  :140:1: note: scanning from here

  Dumping clang ast for 8 modules.

  ^


  error: command failed with exit status: 1


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  
https://reviews.llvm.org/D55575/new/

https://reviews.llvm.org/D55575


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

Re: [Lldb-commits] [lldb] r349175 - [NativePDB] Fix local-variables.cpp test.

[Pavel Labath via lldb-commits]

On 14/12/2018 19:52, Zachary Turner wrote:
I don't know if there's a good way to do that.  Because debuggers need 
to be able to see across multiple translation units, this is implemented 
internally as constructing one giant AST that contains everything for 
the entire program.  LLDB has no notion of a per-module AST, so it would 
be hard to make this work.




That's not how it's implemented now. The code actually iterates through 
all the modules and dumps each one in turn.


  result.GetOutputStream().Printf("Dumping clang ast for %" PRIu64
  " modules.\n",
  (uint64_t)num_modules);
  for (size_t image_idx = 0; image_idx < num_modules; ++image_idx) {
if (m_interpreter.WasInterrupted())
  break;
Module *m = target->GetImages().GetModulePointerAtIndex(image_idx);
SymbolFile *sf = m->GetSymbolVendor()->GetSymbolFile();
sf->DumpClangAST(result.GetOutputStream());
  }


In fact, it looks like this command already supports specifying the 
exact module to dump (either by basename or full path).

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

Re: [Lldb-commits] [PATCH] D55575: [NativePDB] Support local variables

[Zachary Turner via lldb-commits]

An unexpected pass won't make the bot red will it?  If so, one option is to
mark them skip, just to make sure we can get the bot turned on as quickly
as possible.

On Fri, Dec 14, 2018 at 10:56 AM Stella Stamenova 
wrote:

> It’s actually not green – the unexpected passes are counted as a failure.
> With Pavel’s change to add the gcc builder, most of those can now be
> enabled, so I am going to do that today, but there’s still a couple that
> are “unexpectedly passing” when they are in fact failing. We’ll need to fix
> that before making it noisy.
>
>
>
> *From:* Zachary Turner 
> *Sent:* Friday, December 14, 2018 10:53 AM
> *To:* reviews+d55575+public+5ea6161324294...@reviews.llvm.org
> *Cc:* pa...@labath.sk; mose...@google.com; aleksandr.ura...@jetbrains.com;
> amcca...@google.com; clayb...@gmail.com; leonid.mashins...@jetbrains.com;
> Stella Stamenova ; abidh@gmail.com;
> teempe...@gmail.com; apra...@apple.com; jdevliegh...@apple.com;
> lldb-commits@lists.llvm.org; l...@inglorion.net
> *Subject:* Re: [PATCH] D55575: [NativePDB] Support local variables
>
>
>
> I've fixed it.  It looks like the bot should be green again once this test
> starts passing.  Can you make it noisy and starting to send emails now?
>
>
>
> On Fri, Dec 14, 2018 at 10:42 AM Zachary Turner 
> wrote:
>
> Ahh, that seems easy enough to fix.  Just need to change the 7 to a
> {{.*}}.  Since we're actually compiling and running a process on the
> buildbot, different versions of Windows will affect this.
>
>
>
> On Fri, Dec 14, 2018 at 10:39 AM Stella Stamenova via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
> stella.stamenova added a comment.
>
>   $ ":" "RUN: at line 5"
>   $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\lldb.EXE" "-S"
> "E:/build_slave/lldb-x64-windows-ninja/llvm/tools/lldb/lit\lit-lldb-init"
> "-f"
> "E:\build_slave\lldb-x64-windows-ninja\build\tools\lldb\lit\SymbolFile\NativePDB\Output\local-variables.cpp.tmp.exe"
> "-s"
> "E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB/Inputs/local-variables.lldbinit"
>   $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\FileCheck.EXE"
> "E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp"
>   # command stderr:
>
> E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp:154:16:
> error: CHECK-NEXT: expected string not found in input
>
>   // CHECK-NEXT: Dumping clang ast for 7 modules.
>
>  ^
>
>   :140:1: note: scanning from here
>
>   Dumping clang ast for 8 modules.
>
>   ^
>
>
>   error: command failed with exit status: 1
>
>
> Repository:
>   rLLDB LLDB
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D55575/new/
> 
>
> https://reviews.llvm.org/D55575
> 
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D55575: [NativePDB] Support local variables

[Stella Stamenova via lldb-commits]

An unexpected pass makes the bot red. I might un-silence it despite the couple 
of issues left anyway, but it’s something to be aware of.

Thanks,
-Stella

From: Zachary Turner 
Sent: Friday, December 14, 2018 11:04 AM
To: Stella Stamenova 
Cc: reviews+d55575+public+5ea6161324294...@reviews.llvm.org; pa...@labath.sk; 
mose...@google.com; aleksandr.ura...@jetbrains.com; amcca...@google.com; 
clayb...@gmail.com; leonid.mashins...@jetbrains.com; abidh@gmail.com; 
teempe...@gmail.com; apra...@apple.com; jdevliegh...@apple.com; 
lldb-commits@lists.llvm.org; l...@inglorion.net
Subject: Re: [PATCH] D55575: [NativePDB] Support local variables

An unexpected pass won't make the bot red will it?  If so, one option is to 
mark them skip, just to make sure we can get the bot turned on as quickly as 
possible.

On Fri, Dec 14, 2018 at 10:56 AM Stella Stamenova 
mailto:sti...@microsoft.com>> wrote:
It’s actually not green – the unexpected passes are counted as a failure. With 
Pavel’s change to add the gcc builder, most of those can now be enabled, so I 
am going to do that today, but there’s still a couple that are “unexpectedly 
passing” when they are in fact failing. We’ll need to fix that before making it 
noisy.

From: Zachary Turner mailto:ztur...@google.com>>
Sent: Friday, December 14, 2018 10:53 AM
To: 
reviews+d55575+public+5ea6161324294...@reviews.llvm.org
Cc: pa...@labath.sk; 
mose...@google.com; 
aleksandr.ura...@jetbrains.com; 
amcca...@google.com; 
clayb...@gmail.com; 
leonid.mashins...@jetbrains.com; Stella 
Stamenova mailto:sti...@microsoft.com>>; 
abidh@gmail.com; 
teempe...@gmail.com; 
apra...@apple.com; 
jdevliegh...@apple.com; 
lldb-commits@lists.llvm.org; 
l...@inglorion.net
Subject: Re: [PATCH] D55575: [NativePDB] Support local variables

I've fixed it.  It looks like the bot should be green again once this test 
starts passing.  Can you make it noisy and starting to send emails now?

On Fri, Dec 14, 2018 at 10:42 AM Zachary Turner 
mailto:ztur...@google.com>> wrote:
Ahh, that seems easy enough to fix.  Just need to change the 7 to a {{.*}}.  
Since we're actually compiling and running a process on the buildbot, different 
versions of Windows will affect this.

On Fri, Dec 14, 2018 at 10:39 AM Stella Stamenova via Phabricator 
mailto:revi...@reviews.llvm.org>> wrote:
stella.stamenova added a comment.

  $ ":" "RUN: at line 5"
  $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\lldb.EXE" "-S" 
"E:/build_slave/lldb-x64-windows-ninja/llvm/tools/lldb/lit\lit-lldb-init" "-f" 
"E:\build_slave\lldb-x64-windows-ninja\build\tools\lldb\lit\SymbolFile\NativePDB\Output\local-variables.cpp.tmp.exe"
 "-s" 
"E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB/Inputs/local-variables.lldbinit"
  $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\FileCheck.EXE" 
"E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp"
  # command stderr:
  
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp:154:16:
 error: CHECK-NEXT: expected string not found in input

  // CHECK-NEXT: Dumping clang ast for 7 modules.

 ^

  :140:1: note: scanning from here

  Dumping clang ast for 8 modules.

  ^


  error: command failed with exit status: 1


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  
https://reviews.llvm.org/D55575/new/

https://reviews.llvm.org/D55575

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

Re: [Lldb-commits] [PATCH] D55575: [NativePDB] Support local variables

[Zachary Turner via lldb-commits]

If you do decide to unsilence it, then just mark those skip and file bugs
for them being flaky.

On Fri, Dec 14, 2018 at 11:11 AM Stella Stamenova 
wrote:

> An unexpected pass makes the bot red. I might un-silence it despite the
> couple of issues left anyway, but it’s something to be aware of.
>
>
>
> Thanks,
>
> -Stella
>
>
>
> *From:* Zachary Turner 
> *Sent:* Friday, December 14, 2018 11:04 AM
> *To:* Stella Stamenova 
> *Cc:* reviews+d55575+public+5ea6161324294...@reviews.llvm.org;
> pa...@labath.sk; mose...@google.com; aleksandr.ura...@jetbrains.com;
> amcca...@google.com; clayb...@gmail.com; leonid.mashins...@jetbrains.com;
> abidh@gmail.com; teempe...@gmail.com; apra...@apple.com;
> jdevliegh...@apple.com; lldb-commits@lists.llvm.org; l...@inglorion.net
>
>
> *Subject:* Re: [PATCH] D55575: [NativePDB] Support local variables
>
>
>
> An unexpected pass won't make the bot red will it?  If so, one option is
> to mark them skip, just to make sure we can get the bot turned on as
> quickly as possible.
>
>
>
> On Fri, Dec 14, 2018 at 10:56 AM Stella Stamenova 
> wrote:
>
> It’s actually not green – the unexpected passes are counted as a failure.
> With Pavel’s change to add the gcc builder, most of those can now be
> enabled, so I am going to do that today, but there’s still a couple that
> are “unexpectedly passing” when they are in fact failing. We’ll need to fix
> that before making it noisy.
>
>
>
> *From:* Zachary Turner 
> *Sent:* Friday, December 14, 2018 10:53 AM
> *To:* reviews+d55575+public+5ea6161324294...@reviews.llvm.org
> *Cc:* pa...@labath.sk; mose...@google.com; aleksandr.ura...@jetbrains.com;
> amcca...@google.com; clayb...@gmail.com; leonid.mashins...@jetbrains.com;
> Stella Stamenova ; abidh@gmail.com;
> teempe...@gmail.com; apra...@apple.com; jdevliegh...@apple.com;
> lldb-commits@lists.llvm.org; l...@inglorion.net
> *Subject:* Re: [PATCH] D55575: [NativePDB] Support local variables
>
>
>
> I've fixed it.  It looks like the bot should be green again once this test
> starts passing.  Can you make it noisy and starting to send emails now?
>
>
>
> On Fri, Dec 14, 2018 at 10:42 AM Zachary Turner 
> wrote:
>
> Ahh, that seems easy enough to fix.  Just need to change the 7 to a
> {{.*}}.  Since we're actually compiling and running a process on the
> buildbot, different versions of Windows will affect this.
>
>
>
> On Fri, Dec 14, 2018 at 10:39 AM Stella Stamenova via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
> stella.stamenova added a comment.
>
>   $ ":" "RUN: at line 5"
>   $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\lldb.EXE" "-S"
> "E:/build_slave/lldb-x64-windows-ninja/llvm/tools/lldb/lit\lit-lldb-init"
> "-f"
> "E:\build_slave\lldb-x64-windows-ninja\build\tools\lldb\lit\SymbolFile\NativePDB\Output\local-variables.cpp.tmp.exe"
> "-s"
> "E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB/Inputs/local-variables.lldbinit"
>   $ "E:\build_slave\lldb-x64-windows-ninja\build\bin\FileCheck.EXE"
> "E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp"
>   # command stderr:
>
> E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\NativePDB\local-variables.cpp:154:16:
> error: CHECK-NEXT: expected string not found in input
>
>   // CHECK-NEXT: Dumping clang ast for 7 modules.
>
>  ^
>
>   :140:1: note: scanning from here
>
>   Dumping clang ast for 8 modules.
>
>   ^
>
>
>   error: command failed with exit status: 1
>
>
> Repository:
>   rLLDB LLDB
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D55575/new/
> 
>
> https://reviews.llvm.org/D55575
> 
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r349175 - [NativePDB] Fix local-variables.cpp test.

[Zachary Turner via lldb-commits]

Ahh, so I misinterpreted what you originally said.  There is one Clang AST *per
SymboFile*.  In PDB land, compile units are often called "modules" so it's
easy to get confused.  So in my original response, what I actually meant
was that there's no notion of a per compile-unit AST.  But that also had
nothing to do with your question, which was about LLDB modules :)

So anyway, yea the command already supports that as you noted, and
specifying the module basename would also have worked here so that there
would always only be 1 module dumped (turns out, there's only 1 module
dumped anyway because we don't have PDBs for any of the system libraries,
so DumpClangAST is a no-op in those cases).

On Fri, Dec 14, 2018 at 11:00 AM Pavel Labath  wrote:

> On 14/12/2018 19:52, Zachary Turner wrote:
> > I don't know if there's a good way to do that.  Because debuggers need
> > to be able to see across multiple translation units, this is implemented
> > internally as constructing one giant AST that contains everything for
> > the entire program.  LLDB has no notion of a per-module AST, so it would
> > be hard to make this work.
> >
>
> That's not how it's implemented now. The code actually iterates through
> all the modules and dumps each one in turn.
>
>result.GetOutputStream().Printf("Dumping clang ast for %" PRIu64
>" modules.\n",
>(uint64_t)num_modules);
>for (size_t image_idx = 0; image_idx < num_modules; ++image_idx) {
>  if (m_interpreter.WasInterrupted())
>break;
>  Module *m =
> target->GetImages().GetModulePointerAtIndex(image_idx);
>  SymbolFile *sf = m->GetSymbolVendor()->GetSymbolFile();
>  sf->DumpClangAST(result.GetOutputStream());
>}
>
>
> In fact, it looks like this command already supports specifying the
> exact module to dump (either by basename or full path).
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r349180 - Fix Xcode project for MIPS architecture plug-in and move of Event, Listener and Broadcaster to Utility.

[Greg Clayton via lldb-commits]

Author: gclayton
Date: Fri Dec 14 11:22:24 2018
New Revision: 349180

URL: http://llvm.org/viewvc/llvm-project?rev=349180&view=rev
Log:
Fix Xcode project for MIPS architecture plug-in and move of Event, Listener and 
Broadcaster to Utility.

Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=349180&r1=349179&r2=349180&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Fri Dec 14 11:22:24 2018
@@ -110,6 +110,8 @@
23E2E5251D90373D006F38BB /* ArchSpecTest.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 23E2E5161D903689006F38BB /* ArchSpecTest.cpp */; 
};
AF2E02A31FA2CEAF00A86C34 /* ArchitectureArm.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = AF2E02A11FA2CEAF00A86C34 /* ArchitectureArm.cpp 
*/; };
AF2E02A41FA2CEAF00A86C34 /* ArchitectureArm.h in Headers */ = 
{isa = PBXBuildFile; fileRef = AF2E02A21FA2CEAF00A86C34 /* ArchitectureArm.h 
*/; };
+   2647B63221C4366300A81D15 /* ArchitectureMips.cpp in Sources */ 
= {isa = PBXBuildFile; fileRef = 2647B63021C4366300A81D15 /* 
ArchitectureMips.cpp */; };
+   2647B63121C4366300A81D15 /* ArchitectureMips.h in Headers */ = 
{isa = PBXBuildFile; fileRef = 2647B62F21C4366200A81D15 /* ArchitectureMips.h 
*/; };
4C14CEFB2057258D00DEEF94 /* ArchitecturePPC64.cpp in Sources */ 
= {isa = PBXBuildFile; fileRef = 4C14CEF82057258D00DEEF94 /* 
ArchitecturePPC64.cpp */; };
2689007D13353E2200698AC0 /* Args.cpp in Sources */ = {isa = 
PBXBuildFile; fileRef = 26BC7E6C10F1B85900F91463 /* Args.cpp */; };
23CB153C1D66DA9300EDDDE1 /* ArgsTest.cpp in Sources */ = {isa = 
PBXBuildFile; fileRef = 2321F93E1BDD33CE00BA9A93 /* ArgsTest.cpp */; };
@@ -137,7 +139,8 @@
4CCF9F612143014D006CC7EA /* BreakpointResolverScripted.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = 4CCF9F5E2143012F006CC7EA /* 
BreakpointResolverScripted.cpp */; };
2689000713353DB600698AC0 /* BreakpointSite.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 26BC7E1310F1B83100F91463 /* BreakpointSite.cpp 
*/; };
2689000913353DB600698AC0 /* BreakpointSiteList.cpp in Sources 
*/ = {isa = PBXBuildFile; fileRef = 26BC7E1410F1B83100F91463 /* 
BreakpointSiteList.cpp */; };
-   2689003113353E0400698AC0 /* Broadcaster.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 26BC7E6D10F1B85900F91463 /* Broadcaster.cpp */; 
};
+   2647B63A21C436AC00A81D15 /* Broadcaster.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 2647B63921C436AB00A81D15 /* Broadcaster.cpp */; 
};
+   2647B63621C4368300A81D15 /* Broadcaster.h in Headers */ = {isa 
= PBXBuildFile; fileRef = 2647B63521C4368300A81D15 /* Broadcaster.h */; };
23CB15431D66DA9300EDDDE1 /* BroadcasterTest.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 23CB14E61D66CC0E00EDDDE1 /* BroadcasterTest.cpp 
*/; };
949EEDAE1BA7671C008C63CF /* CF.cpp in Sources */ = {isa = 
PBXBuildFile; fileRef = 949EEDAC1BA76719008C63CF /* CF.cpp */; };
2689007613353E1A00698AC0 /* CFCBundle.cpp in Sources */ = {isa 
= PBXBuildFile; fileRef = 26BC7EED10F1B8AD00F91463 /* CFCBundle.cpp */; };
@@ -291,7 +294,8 @@
AFDBC36E204663AF00B9C8F2 /* EmulateInstructionPPC64.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = AFDBC36C204663AF00B9C8F2 /* 
EmulateInstructionPPC64.cpp */; };
9A22A163135E30370024DDC3 /* EmulationStateARM.cpp in Sources */ 
= {isa = PBXBuildFile; fileRef = 9A22A15F135E30370024DDC3 /* 
EmulationStateARM.cpp */; };
6B74D89B200696BB0074051B /* Environment.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 22DC561920064C9600A7E9E8 /* Environment.cpp */; 
};
-   2689003D13353E0400698AC0 /* Event.cpp in Sources */ = {isa = 
PBXBuildFile; fileRef = 26BC7E7910F1B85900F91463 /* Event.cpp */; };
+   2647B63C21C436B400A81D15 /* Event.cpp in Sources */ = {isa = 
PBXBuildFile; fileRef = 2647B63B21C436B400A81D15 /* Event.cpp */; };
+   2647B63421C4367A00A81D15 /* Event.h in Headers */ = {isa = 
PBXBuildFile; fileRef = 2647B63321C4367A00A81D15 /* Event.h */; };
2660387A211CA90F00329572 /* ExceptionBreakpoint.cpp in Sources 
*/ = {isa = PBXBuildFile; fileRef = 26603874211CA90E00329572 /* 
ExceptionBreakpoint.cpp */; };
268900EB13353E6F00698AC0 /* ExecutionContext.cpp in Sources */ 
= {isa = PBXBuildFile; fileRef = 26BC7F3510F1B90C00F91463 /* 
ExecutionContext.cpp */; };
4C88BC2A1BA3722B00AA0964 /* Expression.cpp in Sources */ = {isa 
= PBXBuildFile; fileRef = 4C88BC291BA3722B00AA0964 /* Expression.cpp */; };
@@ -399,7 +403,8 @@
   

[Lldb-commits] [PATCH] D55430: build.py: Implement "gcc" builder

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

I am trying to use the new builder to build the lldb-mi tests, so that they can 
start consistently passing on Windows, so they're now using the gcc builder on 
Linux and failing:

  2018-12-14T19:24:41.8890855Z 
  2018-12-14T19:24:41.8904193Z Testing: 0 .. 10.. 20.. 30.
  2018-12-14T19:24:41.8918035Z FAIL: LLDB :: 
tools/lldb-mi/exec/exec-interrupt.test (17141 of 45941)
  2018-12-14T19:24:41.8932384Z  TEST 'LLDB :: 
tools/lldb-mi/exec/exec-interrupt.test' FAILED 
  2018-12-14T19:24:41.8945979Z Script:
  2018-12-14T19:24:41.8959648Z --
  2018-12-14T19:24:41.8974664Z : 'RUN: at line 1';   '/usr/bin/python2.7' 
/vstsdrive/_work/42/s/llvm/tools/lldb/lit/helper/build.py --compiler=any 
--arch=64 --tools-dir=/vstsdrive/_work/42/b/LLVMBuild/./bin 
/vstsdrive/_work/42/s/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/main.c 
--nodefaultlib -o 
/vstsdrive/_work/42/b/LLVMBuild/tools/lldb/lit/tools/lldb-mi/exec/Output/exec-interrupt.test.tmp
  2018-12-14T19:24:41.8991443Z : 'RUN: at line 2';   
/vstsdrive/_work/42/b/LLVMBuild/bin/lldb-mi --synchronous 
/vstsdrive/_work/42/b/LLVMBuild/tools/lldb/lit/tools/lldb-mi/exec/Output/exec-interrupt.test.tmp
 < 
/vstsdrive/_work/42/s/llvm/tools/lldb/lit/tools/lldb-mi/exec/exec-interrupt.test
 | /vstsdrive/_work/42/b/LLVMBuild/bin/FileCheck 
/vstsdrive/_work/42/s/llvm/tools/lldb/lit/tools/lldb-mi/exec/exec-interrupt.test
  2018-12-14T19:24:41.9006101Z --
  2018-12-14T19:24:41.9019550Z Exit Code: 1
  2018-12-14T19:24:41.9026154Z 
  2018-12-14T19:24:41.9039902Z Command Output (stdout):
  2018-12-14T19:24:41.9053450Z --
  2018-12-14T19:24:41.9066966Z Cleaning exec-interrupt.test.tmp-main.o
  2018-12-14T19:24:41.9081046Z Cleaning exec-interrupt.test.tmp
  2018-12-14T19:24:41.9087711Z 
  2018-12-14T19:24:41.9094525Z 
  2018-12-14T19:24:41.9101310Z 
  2018-12-14T19:24:41.9114993Z compiling main.c -> 
exec-interrupt.test.tmp-main.o
  2018-12-14T19:24:41.9128817Z   STDOUT:
  2018-12-14T19:24:41.9135428Z 
  2018-12-14T19:24:41.9142241Z 
  2018-12-14T19:24:41.9149031Z 
  2018-12-14T19:24:41.9155781Z 
  2018-12-14T19:24:41.9169689Z linking exec-interrupt.test.tmp-main.o -> 
exec-interrupt.test.tmp
  2018-12-14T19:24:41.9183153Z   STDOUT:
  2018-12-14T19:24:41.9190134Z 
  2018-12-14T19:24:41.9203611Z   STDERR:
  2018-12-14T19:24:41.9217412Z clang-8: error: unable to execute command: 
Executable "ld" doesn't exist!
  2018-12-14T19:24:41.9231640Z clang-8: error: linker command failed with 
exit code 1 (use -v to see invocation)
  2018-12-14T19:24:41.9238695Z 
  2018-12-14T19:24:41.9245289Z 
  2018-12-14T19:24:41.9258832Z --


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55430/new/

https://reviews.llvm.org/D55430



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

[Lldb-commits] [lldb] r349182 - Cache memory regions in ProcessMinidump and use the linux maps as the source of the information if available

[Greg Clayton via lldb-commits]

Author: gclayton
Date: Fri Dec 14 11:36:01 2018
New Revision: 349182

URL: http://llvm.org/viewvc/llvm-project?rev=349182&view=rev
Log:
Cache memory regions in ProcessMinidump and use the linux maps as the source of 
the information if available

Breakpad creates minidump files that sometimes have:
- linux maps textual content
- no MemoryInfoList

Right now unless the file has a MemoryInfoList we get no region information.

This patch:

- reads and caches the memory region info one time and sorts it for easy 
subsequent access
- get the region info from the best source in this order:
  - linux maps info (if available)
  - MemoryInfoList (if available)
  - MemoryList or Memory64List
- returns memory region info for the gaps between regions (before the first and 
after the last)

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


Added:
lldb/trunk/source/Plugins/Process/Utility/LinuxProcMaps.cpp
lldb/trunk/source/Plugins/Process/Utility/LinuxProcMaps.h
lldb/trunk/unittests/Process/minidump/Inputs/regions-linux-map.dmp   (with 
props)
lldb/trunk/unittests/Process/minidump/Inputs/regions-memlist.dmp   (with 
props)
lldb/trunk/unittests/Process/minidump/Inputs/regions-memlist64.dmp   (with 
props)
Modified:
lldb/trunk/include/lldb/Target/MemoryRegionInfo.h
lldb/trunk/lldb.xcodeproj/project.pbxproj
lldb/trunk/source/Plugins/Process/Utility/CMakeLists.txt
lldb/trunk/source/Plugins/Process/minidump/MinidumpParser.cpp
lldb/trunk/source/Plugins/Process/minidump/MinidumpParser.h
lldb/trunk/source/Plugins/Process/minidump/MinidumpTypes.h
lldb/trunk/source/Plugins/Process/minidump/ProcessMinidump.cpp
lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp

Modified: lldb/trunk/include/lldb/Target/MemoryRegionInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/MemoryRegionInfo.h?rev=349182&r1=349181&r2=349182&view=diff
==
--- lldb/trunk/include/lldb/Target/MemoryRegionInfo.h (original)
+++ lldb/trunk/include/lldb/Target/MemoryRegionInfo.h Fri Dec 14 11:36:01 2018
@@ -109,6 +109,20 @@ protected:
   OptionalBool m_flash;
   lldb::offset_t m_blocksize;
 };
+  
+inline bool operator<(const MemoryRegionInfo &lhs,
+  const MemoryRegionInfo &rhs) {
+  return lhs.GetRange() < rhs.GetRange();
+}
+
+inline bool operator<(const MemoryRegionInfo &lhs, lldb::addr_t rhs) {
+  return lhs.GetRange().GetRangeBase() < rhs;
+}
+
+inline bool operator<(lldb::addr_t lhs, const MemoryRegionInfo &rhs) {
+  return lhs < rhs.GetRange().GetRangeBase();
+}
+
 }
 
 namespace llvm {

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=349182&r1=349181&r2=349182&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Fri Dec 14 11:36:01 2018
@@ -402,6 +402,8 @@
4CDB8D6D1DBA91B6006C5B13 /* LibStdcppUniquePointer.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = 4CDB8D671DBA91A6006C5B13 /* 
LibStdcppUniquePointer.cpp */; };
268900DA13353E6F00698AC0 /* LineEntry.cpp in Sources */ = {isa 
= PBXBuildFile; fileRef = 26BC7F1910F1B8EC00F91463 /* LineEntry.cpp */; };
268900DB13353E6F00698AC0 /* LineTable.cpp in Sources */ = {isa 
= PBXBuildFile; fileRef = 26BC7F1A10F1B8EC00F91463 /* LineTable.cpp */; };
+   2647B64421C43BB000A81D15 /* LinuxProcMaps.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 2647B64221C43BB000A81D15 /* LinuxProcMaps.cpp 
*/; };
+   2647B64321C43BB000A81D15 /* LinuxProcMaps.h in Headers */ = 
{isa = PBXBuildFile; fileRef = 2647B64121C43BAF00A81D15 /* LinuxProcMaps.h */; 
};
23059A0719532B96007B8189 /* LinuxSignals.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 23059A0519532B96007B8189 /* LinuxSignals.cpp */; 
};
2647B63E21C436BD00A81D15 /* Listener.cpp in Sources */ = {isa = 
PBXBuildFile; fileRef = 2647B63D21C436BC00A81D15 /* Listener.cpp */; };
2647B63821C4369500A81D15 /* Listener.h in Headers */ = {isa = 
PBXBuildFile; fileRef = 2647B63721C4369500A81D15 /* Listener.h */; };
@@ -2050,6 +2052,8 @@
26BC7C5B10F1B6E900F91463 /* LineEntry.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
LineEntry.h; path = include/lldb/Symbol/LineEntry.h; sourceTree = ""; };
26BC7F1A10F1B8EC00F91463 /* LineTable.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = LineTable.cpp; path = source/Symbol/LineTable.cpp; sourceTree = 
""; };
26BC7C5C10F1B6E900F91463 /* LineTable.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
LineTable.h; path = in

[Lldb-commits] [PATCH] D55522: Cache memory regions in ProcessMinidump and use the linux maps as the source of the information if available.

[Phabricator via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL349182: Cache memory regions in ProcessMinidump and use the 
linux maps as the source of… (authored by gclayton, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D55522?vs=178168&id=178260#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55522/new/

https://reviews.llvm.org/D55522

Files:
  lldb/trunk/include/lldb/Target/MemoryRegionInfo.h
  lldb/trunk/lldb.xcodeproj/project.pbxproj
  lldb/trunk/source/Plugins/Process/Utility/CMakeLists.txt
  lldb/trunk/source/Plugins/Process/Utility/LinuxProcMaps.cpp
  lldb/trunk/source/Plugins/Process/Utility/LinuxProcMaps.h
  lldb/trunk/source/Plugins/Process/minidump/MinidumpParser.cpp
  lldb/trunk/source/Plugins/Process/minidump/MinidumpParser.h
  lldb/trunk/source/Plugins/Process/minidump/MinidumpTypes.h
  lldb/trunk/source/Plugins/Process/minidump/ProcessMinidump.cpp
  lldb/trunk/unittests/Process/minidump/Inputs/regions-linux-map.dmp
  lldb/trunk/unittests/Process/minidump/Inputs/regions-memlist.dmp
  lldb/trunk/unittests/Process/minidump/Inputs/regions-memlist64.dmp
  lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp

Index: lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp
===
--- lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp
+++ lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp
@@ -300,29 +300,120 @@
   EXPECT_FALSE(parser->FindMemoryRange(0x7ffe + 4096).hasValue());
 }
 
-void check_region_info(std::unique_ptr &parser,
-   const uint64_t addr, MemoryRegionInfo::OptionalBool read,
-   MemoryRegionInfo::OptionalBool write,
-   MemoryRegionInfo::OptionalBool exec) {
+void check_region(std::unique_ptr &parser,
+  lldb::addr_t addr, lldb::addr_t start, lldb::addr_t end,
+  MemoryRegionInfo::OptionalBool read,
+  MemoryRegionInfo::OptionalBool write,
+  MemoryRegionInfo::OptionalBool exec,
+  MemoryRegionInfo::OptionalBool mapped,
+  ConstString name = ConstString()) {
   auto range_info = parser->GetMemoryRegionInfo(addr);
-  ASSERT_TRUE(range_info.hasValue());
-  EXPECT_EQ(read, range_info->GetReadable());
-  EXPECT_EQ(write, range_info->GetWritable());
-  EXPECT_EQ(exec, range_info->GetExecutable());
+  EXPECT_EQ(start, range_info.GetRange().GetRangeBase());
+  EXPECT_EQ(end, range_info.GetRange().GetRangeEnd());
+  EXPECT_EQ(read, range_info.GetReadable());
+  EXPECT_EQ(write, range_info.GetWritable());
+  EXPECT_EQ(exec, range_info.GetExecutable());
+  EXPECT_EQ(mapped, range_info.GetMapped());
+  EXPECT_EQ(name, range_info.GetName());
+}
+
+// Same as above function where addr == start
+void check_region(std::unique_ptr &parser,
+  lldb::addr_t start, lldb::addr_t end,
+  MemoryRegionInfo::OptionalBool read,
+  MemoryRegionInfo::OptionalBool write,
+  MemoryRegionInfo::OptionalBool exec,
+  MemoryRegionInfo::OptionalBool mapped,
+  ConstString name = ConstString()) {
+  check_region(parser, start, start, end, read, write, exec, mapped, name);
 }
 
+
+constexpr auto yes = MemoryRegionInfo::eYes;
+constexpr auto no = MemoryRegionInfo::eNo;
+constexpr auto unknown = MemoryRegionInfo::eDontKnow;
+
 TEST_F(MinidumpParserTest, GetMemoryRegionInfo) {
   SetUpData("fizzbuzz_wow64.dmp");
 
-  const auto yes = MemoryRegionInfo::eYes;
-  const auto no = MemoryRegionInfo::eNo;
-
-  check_region_info(parser, 0x0, no, no, no);
-  check_region_info(parser, 0x1, yes, yes, no);
-  check_region_info(parser, 0x2, yes, yes, no);
-  check_region_info(parser, 0x3, yes, yes, no);
-  check_region_info(parser, 0x31000, no, no, no);
-  check_region_info(parser, 0x4, yes, no, no);
+  check_region(parser, 0x, 0x0001, no, no, no, no);
+  check_region(parser, 0x0001, 0x0002, yes, yes, no, yes);
+  check_region(parser, 0x0002, 0x0003, yes, yes, no, yes);
+  check_region(parser, 0x0003, 0x00031000, yes, yes, no, yes);
+  check_region(parser, 0x00031000, 0x0004, no, no, no, no);
+  check_region(parser, 0x0004, 0x00041000, yes, no, no, yes);
+
+  // Check addresses contained inside ranges
+  check_region(parser, 0x0001, 0x, 0x0001, no, no, no, no);
+  check_region(parser, 0x, 0x, 0x0001, no, no, no, no);
+  check_region(parser, 0x00010001, 0x0001, 0x0002, yes, yes, no, yes);
+  check_region(parser, 0x0001, 0x0001, 0x0002, yes, yes, no, yes);
+
+  // Test that an address after the last entry maps to rest of the memory space
+  check_region(parser, 0x7fff, 0x7fff, UINT64_MAX, no, no, no, no);
+}
+
+TEST_F(MinidumpParserTest, GetMe

[Lldb-commits] [lldb] r349183 - Add missing .dmp files to test inputs.

[Greg Clayton via lldb-commits]

Author: gclayton
Date: Fri Dec 14 11:38:08 2018
New Revision: 349183

URL: http://llvm.org/viewvc/llvm-project?rev=349183&view=rev
Log:
Add missing .dmp files to test inputs.


Modified:
lldb/trunk/unittests/Process/minidump/CMakeLists.txt

Modified: lldb/trunk/unittests/Process/minidump/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Process/minidump/CMakeLists.txt?rev=349183&r1=349182&r2=349183&view=diff
==
--- lldb/trunk/unittests/Process/minidump/CMakeLists.txt (original)
+++ lldb/trunk/unittests/Process/minidump/CMakeLists.txt Fri Dec 14 11:38:08 
2018
@@ -26,6 +26,9 @@ set(test_inputs
module-list-padded.dmp
modules-dup-min-addr.dmp
modules-order.dmp
+   regions-linux-map.dmp
+   regions-memlist.dmp
+   regions-memlist64.dmp
thread-list-not-padded.dmp
thread-list-padded.dmp
)


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

[Lldb-commits] [PATCH] D55522: Cache memory regions in ProcessMinidump and use the linux maps as the source of the information if available.

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

Fixed the test inputs CMakeLists.txt file:

$ svn commit
SendingCMakeLists.txt
Transmitting file data .done
Committing transaction...
Committed revision 349183.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55522/new/

https://reviews.llvm.org/D55522



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

Re: [Lldb-commits] [PATCH] D55430: build.py: Implement "gcc" builder

[Pavel Labath via lldb-commits]

On 14/12/2018 20:32, Stella Stamenova via Phabricator wrote:

stella.stamenova added a comment.

I am trying to use the new builder to build the lldb-mi tests, so that they can 
start consistently passing on Windows, so they're now using the gcc builder on 
Linux and failing:


Interesting. Can you run the script in verbose mode so I can see the 
exact commands it executes?


Not being able to find the linker is weird. Can you check whether you 
have /usr/bin/ld on your system? Maybe we need to add something to the 
PATH? Is that clang binary capable of producing executables when you run 
it manually?

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

Re: [Lldb-commits] [PATCH] D55430: build.py: Implement "gcc" builder

[Stella Stamenova via lldb-commits]

The verbose output is below. If I run the two commands on the command line, 
they both succeed, but when I run them through build.py, the link command is 
failing. I suspect that the process that gets created through python doesn't 
inherit the environment with the PATH set, so it can't find the linker.


compiling main.c -> exec-next-instruction.test.tmp-main.o
  Command Line: /vstsdrive/_work/42/b/LLVMBuild/bin/clang++ -m64 -g -O0 
-nostdinc -static -c -o 
/vstsdrive/_work/42/b/LLVMBuild/tools/lldb/lit/tools/lldb-mi/exec/Output/exec-next-instruction.test.tmp-main.o
 /vstsdrive/_work/42/s/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/main.c
  Env:
  STDOUT:




linking exec-next-instruction.test.tmp-main.o -> exec-next-instruction.test.tmp
  Command Line: /vstsdrive/_work/42/b/LLVMBuild/bin/clang++ -m64 -nostdlib 
-static -Wl,-e,main -o 
/vstsdrive/_work/42/b/LLVMBuild/tools/lldb/lit/tools/lldb-mi/exec/Output/exec-next-instruction.test.tmp
 
/vstsdrive/_work/42/b/LLVMBuild/tools/lldb/lit/tools/lldb-mi/exec/Output/exec-next-instruction.test.tmp-main.o
  Env:
  STDOUT:

  STDERR:
clang-8: error: unable to execute command: Executable "ld" doesn't exist!
clang-8: error: linker command failed with exit code 1 (use -v to see 
invocation)



-Original Message-
From: Pavel Labath  
Sent: Friday, December 14, 2018 11:48 AM
To: reviews+d55430+public+4cf420cdda71e...@reviews.llvm.org; 
ztur...@google.com; Stella Stamenova 
Cc: llvm-comm...@lists.llvm.org; joker@gmail.com; dexonsm...@apple.com; 
lldb-commits@lists.llvm.org
Subject: Re: [PATCH] D55430: build.py: Implement "gcc" builder

On 14/12/2018 20:32, Stella Stamenova via Phabricator wrote:
> stella.stamenova added a comment.
> 
> I am trying to use the new builder to build the lldb-mi tests, so that they 
> can start consistently passing on Windows, so they're now using the gcc 
> builder on Linux and failing:

Interesting. Can you run the script in verbose mode so I can see the exact 
commands it executes?

Not being able to find the linker is weird. Can you check whether you have 
/usr/bin/ld on your system? Maybe we need to add something to the PATH? Is that 
clang binary capable of producing executables when you run it manually?
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D55430: build.py: Implement "gcc" builder

[Zachary Turner via lldb-commits]

Don't we print the environment in verbose mode?  Can we see that output as
well?

On Fri, Dec 14, 2018 at 11:53 AM Stella Stamenova 
wrote:

> The verbose output is below. If I run the two commands on the command
> line, they both succeed, but when I run them through build.py, the link
> command is failing. I suspect that the process that gets created through
> python doesn't inherit the environment with the PATH set, so it can't find
> the linker.
>
>
> compiling main.c -> exec-next-instruction.test.tmp-main.o
>   Command Line: /vstsdrive/_work/42/b/LLVMBuild/bin/clang++ -m64 -g -O0
> -nostdinc -static -c -o
> /vstsdrive/_work/42/b/LLVMBuild/tools/lldb/lit/tools/lldb-mi/exec/Output/exec-next-instruction.test.tmp-main.o
> /vstsdrive/_work/42/s/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/main.c
>   Env:
>   STDOUT:
>
>
>
>
> linking exec-next-instruction.test.tmp-main.o ->
> exec-next-instruction.test.tmp
>   Command Line: /vstsdrive/_work/42/b/LLVMBuild/bin/clang++ -m64 -nostdlib
> -static -Wl,-e,main -o
> /vstsdrive/_work/42/b/LLVMBuild/tools/lldb/lit/tools/lldb-mi/exec/Output/exec-next-instruction.test.tmp
> /vstsdrive/_work/42/b/LLVMBuild/tools/lldb/lit/tools/lldb-mi/exec/Output/exec-next-instruction.test.tmp-main.o
>   Env:
>   STDOUT:
>
>   STDERR:
> clang-8: error: unable to execute command: Executable "ld" doesn't
> exist!
> clang-8: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
>
>
> -Original Message-
> From: Pavel Labath 
> Sent: Friday, December 14, 2018 11:48 AM
> To: reviews+d55430+public+4cf420cdda71e...@reviews.llvm.org;
> ztur...@google.com; Stella Stamenova 
> Cc: llvm-comm...@lists.llvm.org; joker@gmail.com; dexonsm...@apple.com;
> lldb-commits@lists.llvm.org
> Subject: Re: [PATCH] D55430: build.py: Implement "gcc" builder
>
> On 14/12/2018 20:32, Stella Stamenova via Phabricator wrote:
> > stella.stamenova added a comment.
> >
> > I am trying to use the new builder to build the lldb-mi tests, so that
> they can start consistently passing on Windows, so they're now using the
> gcc builder on Linux and failing:
>
> Interesting. Can you run the script in verbose mode so I can see the exact
> commands it executes?
>
> Not being able to find the linker is weird. Can you check whether you have
> /usr/bin/ld on your system? Maybe we need to add something to the PATH? Is
> that clang binary capable of producing executables when you run it manually?
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D55430: build.py: Implement "gcc" builder

[Stella Stamenova via lldb-commits]

Ah, yes, it does. It looks like it does contain /usr/bin.

Script Arguments:
  Arch: 64
  Compiler: any
  Outdir: 
/vstsdrive/_work/42/b/LLVMBuild/tools/lldb/lit/tools/lldb-mi/exec/Output
  Output: 
/vstsdrive/_work/42/b/LLVMBuild/tools/lldb/lit/tools/lldb-mi/exec/Output/exec-next-instruction.test.tmp
  Nodefaultlib: True
  Opt: none
  Mode: compile-and-link
  Clean: True
  Verbose: True
  Dryrun: False
  Inputs: 
/vstsdrive/_work/42/s/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/main.c
Script Environment:
LANG = en_US.UTF-8
TERM = xterm
SHELL = /bin/bash
LESSCLOSE = /usr/bin/lesspipe %s %s
XDG_RUNTIME_DIR = /run/user/1000
SHLVL = 1
SSH_TTY = /dev/pts/0
OLDPWD = /vstsdrive/_work/42/b
PWD = /vstsdrive/_work/42/b/LLVMBuild
LESSOPEN = | /usr/bin/lesspipe %s
XDG_DATA_DIRS = /usr/local/share
/usr/share
/var/lib/snapd/desktop
SSH_CLIENT = 10.137.82.74 60442 22
LOGNAME = e2admin
USER = e2admin
PATH = /home/e2admin/bin
   /home/e2admin/.local/bin
   /usr/local/sbin
   /usr/local/bin
   /usr/sbin
   /usr/bin
   /sbin
   /bin
   /usr/games
   /usr/local/games
   /snap/bin
HOME = /home/e2admin
MAIL = /var/mail/e2admin

From: Zachary Turner 
Sent: Friday, December 14, 2018 11:56 AM
To: Stella Stamenova 
Cc: Pavel Labath ; 
reviews+d55430+public+4cf420cdda71e...@reviews.llvm.org; 
llvm-comm...@lists.llvm.org; joker@gmail.com; dexonsm...@apple.com; 
lldb-commits@lists.llvm.org
Subject: Re: [PATCH] D55430: build.py: Implement "gcc" builder

Don't we print the environment in verbose mode?  Can we see that output as well?

On Fri, Dec 14, 2018 at 11:53 AM Stella Stamenova 
mailto:sti...@microsoft.com>> wrote:
The verbose output is below. If I run the two commands on the command line, 
they both succeed, but when I run them through build.py, the link command is 
failing. I suspect that the process that gets created through python doesn't 
inherit the environment with the PATH set, so it can't find the linker.


compiling main.c -> exec-next-instruction.test.tmp-main.o
  Command Line: /vstsdrive/_work/42/b/LLVMBuild/bin/clang++ -m64 -g -O0 
-nostdinc -static -c -o 
/vstsdrive/_work/42/b/LLVMBuild/tools/lldb/lit/tools/lldb-mi/exec/Output/exec-next-instruction.test.tmp-main.o
 /vstsdrive/_work/42/s/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/main.c
  Env:
  STDOUT:




linking exec-next-instruction.test.tmp-main.o -> exec-next-instruction.test.tmp
  Command Line: /vstsdrive/_work/42/b/LLVMBuild/bin/clang++ -m64 -nostdlib 
-static -Wl,-e,main -o 
/vstsdrive/_work/42/b/LLVMBuild/tools/lldb/lit/tools/lldb-mi/exec/Output/exec-next-instruction.test.tmp
 
/vstsdrive/_work/42/b/LLVMBuild/tools/lldb/lit/tools/lldb-mi/exec/Output/exec-next-instruction.test.tmp-main.o
  Env:
  STDOUT:

  STDERR:
clang-8: error: unable to execute command: Executable "ld" doesn't exist!
clang-8: error: linker command failed with exit code 1 (use -v to see 
invocation)



-Original Message-
From: Pavel Labath mailto:pa...@labath.sk>>
Sent: Friday, December 14, 2018 11:48 AM
To: 
reviews+d55430+public+4cf420cdda71e...@reviews.llvm.org;
 ztur...@google.com; Stella Stamenova 
mailto:sti...@microsoft.com>>
Cc: llvm-comm...@lists.llvm.org; 
joker@gmail.com; 
dexonsm...@apple.com; 
lldb-commits@lists.llvm.org
Subject: Re: [PATCH] D55430: build.py: Implement "gcc" builder

On 14/12/2018 20:32, Stella Stamenova via Phabricator wrote:
> stella.stamenova added a comment.
>
> I am trying to use the new builder to build the lldb-mi tests, so that they 
> can start consistently passing on Windows, so they're now using the gcc 
> builder on Linux and failing:

Interesting. Can you run the script in verbose mode so I can see the exact 
commands it executes?

Not being able to find the linker is weird. Can you check whether you have 
/usr/bin/ld on your system? Maybe we need to add something to the PATH? Is that 
clang binary capable of producing executables when you run it manually?
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D55608: Make crashlog.py work or binaries with spaces in their names

[Jim Ingham via Phabricator via lldb-commits]

jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.

The frame regex will get confused if you had a binary called "foo 0x1"  Then we 
would treat "foo" as the binary name, 0x1 as the pc, and the rest would be the 
function name.  I don't see how to avoid that altogether.  Maybe we could 
insist that the address have at least 8 numbers in it?  Then your binary would 
have to be called "foo 0x123456789" before we get confused, at which point my 
caring level has dropped pretty low.

I'm not sure about the image regex.  In the part where we are grabbing version 
numbers, you've replaced:

([^<]+)

with

([0-9a-zA-Z_]+)

In crashlogs, I see lines like:

  0x10b60b000 -0x10f707fff  com.apple.LLDB.framework (1.1000.11.38.2 - 
1000.11.38.2) <96E36F5C-1A83-39A1-8713-5FDD9701C3F1> 
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/LLDB

In the first form "([^<]+)" will grab "(1.1000.11.38.2 - 1000.11.38.2) ".  I 
presume we just discard this bit.  But ([0-9a-zA-Z_]+)  will stop at the 
first"(" for the version number, won't it?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55608/new/

https://reviews.llvm.org/D55608



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

[Lldb-commits] [PATCH] D55559: Remove the Disassembly benchmarks.

[Jim Ingham via Phabricator via lldb-commits]

jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

LGTM


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D9/new/

https://reviews.llvm.org/D9



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

[Lldb-commits] [lldb] r349194 - Remove the Disassembly benchmarks.

[Adrian Prantl via lldb-commits]

Author: adrian
Date: Fri Dec 14 13:06:00 2018
New Revision: 349194

URL: http://llvm.org/viewvc/llvm-project?rev=349194&view=rev
Log:
Remove the Disassembly benchmarks.

While I was out hunting for remaining pexpect-based tests, I came
across these tests that can't possibly work an any modern system, as
they rely on having gdb available in /Developer.

This patch simply removes the test without replacement.

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

Removed:

lldb/trunk/packages/Python/lldbsuite/test/benchmarks/disassembly/TestDisassembly.py

lldb/trunk/packages/Python/lldbsuite/test/benchmarks/disassembly/TestDoAttachThenDisassembly.py

lldb/trunk/packages/Python/lldbsuite/test/benchmarks/disassembly/TestXcode41Vs42GDBDisassembly.py

Removed: 
lldb/trunk/packages/Python/lldbsuite/test/benchmarks/disassembly/TestDisassembly.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/benchmarks/disassembly/TestDisassembly.py?rev=349193&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/benchmarks/disassembly/TestDisassembly.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/benchmarks/disassembly/TestDisassembly.py
 (removed)
@@ -1,165 +0,0 @@
-"""Disassemble lldb's Driver::MainLoop() functions comparing lldb against 
gdb."""
-
-from __future__ import print_function
-
-
-import os
-import sys
-import lldb
-from lldbsuite.test.decorators import *
-from lldbsuite.test.lldbbench import *
-from lldbsuite.test.lldbtest import *
-from lldbsuite.test import lldbutil
-
-
-def is_exe(fpath):
-"""Returns true if fpath is an executable."""
-return os.path.isfile(fpath) and os.access(fpath, os.X_OK)
-
-
-class DisassembleDriverMainLoop(BenchBase):
-
-mydir = TestBase.compute_mydir(__file__)
-
-def setUp(self):
-"""
-Note that lldbtest_config.lldbExec can be specified with the LLDB_EXEC 
env variable (see
-dotest.py), and gdbExec can be specified with the GDB_EXEC env 
variable.
-This provides a flexibility in specifying different versions of gdb for
-comparison purposes.
-"""
-BenchBase.setUp(self)
-# If env var GDB_EXEC is specified, use it; otherwise, use gdb in your
-# PATH env var.
-if "GDB_EXEC" in os.environ and is_exe(os.environ["GDB_EXEC"]):
-self.gdbExec = os.environ["GDB_EXEC"]
-else:
-self.gdbExec = "gdb"
-
-self.exe = lldbtest_config.lldbExec
-self.function = 'Driver::MainLoop()'
-self.lldb_avg = None
-self.gdb_avg = None
-self.count = 5
-
-@benchmarks_test
-@no_debug_info_test
-@expectedFailureAll(
-oslist=["windows"],
-bugnumber="llvm.org/pr22274: need a pexpect replacement for windows")
-def test_run_lldb_then_gdb(self):
-"""Test disassembly on a large function with lldb vs. gdb."""
-print()
-print("lldb path: %s" % lldbtest_config.lldbExec)
-print("gdb path: %s" % self.gdbExec)
-
-print()
-self.run_lldb_disassembly(self.exe, self.function, self.count)
-print("lldb benchmark:", self.stopwatch)
-self.run_gdb_disassembly(self.exe, self.function, self.count)
-print("gdb benchmark:", self.stopwatch)
-print("lldb_avg/gdb_avg: %f" % (self.lldb_avg / self.gdb_avg))
-
-@benchmarks_test
-@no_debug_info_test
-@expectedFailureAll(
-oslist=["windows"],
-bugnumber="llvm.org/pr22274: need a pexpect replacement for windows")
-def test_run_gdb_then_lldb(self):
-"""Test disassembly on a large function with lldb vs. gdb."""
-print()
-print("lldb path: %s" % lldbtest_config.lldbExec)
-print("gdb path: %s" % self.gdbExec)
-
-print()
-self.run_gdb_disassembly(self.exe, self.function, self.count)
-print("gdb benchmark:", self.stopwatch)
-self.run_lldb_disassembly(self.exe, self.function, self.count)
-print("lldb benchmark:", self.stopwatch)
-print("lldb_avg/gdb_avg: %f" % (self.lldb_avg / self.gdb_avg))
-
-def run_lldb_disassembly(self, exe, function, count):
-import pexpect
-# Set self.child_prompt, which is "(lldb) ".
-self.child_prompt = '(lldb) '
-prompt = self.child_prompt
-
-# So that the child gets torn down after the test.
-self.child = pexpect.spawn(
-'%s %s %s' %
-(lldbtest_config.lldbExec, self.lldbOption, exe))
-child = self.child
-
-# Turn on logging for what the child sends back.
-if self.TraceOn():
-child.logfile_read = sys.stdout
-
-child.expect_exact(prompt)
-child.sendline('breakpoint set -F %s' % function)
-child.expect_exact(prompt)
-child.sendline('run')
-child.expect_exact(prompt)
-
-# Reset the stopwatch now.
- 

[Lldb-commits] [PATCH] D55559: Remove the Disassembly benchmarks.

[Phabricator via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB349194: Remove the Disassembly benchmarks. (authored by 
adrian, committed by ).

Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D9/new/

https://reviews.llvm.org/D9

Files:
  packages/Python/lldbsuite/test/benchmarks/disassembly/TestDisassembly.py
  
packages/Python/lldbsuite/test/benchmarks/disassembly/TestDoAttachThenDisassembly.py
  
packages/Python/lldbsuite/test/benchmarks/disassembly/TestXcode41Vs42GDBDisassembly.py

Index: packages/Python/lldbsuite/test/benchmarks/disassembly/TestDoAttachThenDisassembly.py
===
--- packages/Python/lldbsuite/test/benchmarks/disassembly/TestDoAttachThenDisassembly.py
+++ packages/Python/lldbsuite/test/benchmarks/disassembly/TestDoAttachThenDisassembly.py
@@ -1,70 +0,0 @@
-"""Test lldb's disassemblt speed.  This bench deliberately attaches to an lldb
-inferior and traverses the stack for thread0 to arrive at frame with function
-'MainLoop'.  It is important to specify an lldb executable as the inferior."""
-
-from __future__ import print_function
-
-
-import os
-import sys
-import lldb
-from lldbsuite.test.decorators import *
-from lldbsuite.test.lldbbench import *
-from lldbsuite.test.lldbtest import *
-
-
-class AttachThenDisassemblyBench(BenchBase):
-
-mydir = TestBase.compute_mydir(__file__)
-
-def setUp(self):
-BenchBase.setUp(self)
-self.exe = lldbtest_config.lldbExec
-self.count = 10
-
-@benchmarks_test
-@no_debug_info_test
-def test_attach_then_disassembly(self):
-"""Attach to a spawned lldb process then run disassembly benchmarks."""
-print()
-self.run_lldb_attach_then_disassembly(self.exe, self.count)
-print("lldb disassembly benchmark:", self.stopwatch)
-
-def run_lldb_attach_then_disassembly(self, exe, count):
-target = self.dbg.CreateTarget(exe)
-
-# Spawn a new process and don't display the stdout if not in TraceOn()
-# mode.
-import subprocess
-popen = subprocess.Popen([exe, self.lldbOption], stdout=open(
-os.devnull, 'w') if not self.TraceOn() else None)
-if self.TraceOn():
-print("pid of spawned process: %d" % popen.pid)
-
-# Attach to the launched lldb process.
-listener = lldb.SBListener("my.attach.listener")
-error = lldb.SBError()
-process = target.AttachToProcessWithID(listener, popen.pid, error)
-
-# Set thread0 as the selected thread, followed by the 'MainLoop' frame
-# as the selected frame.  Then do disassembly on the function.
-thread0 = process.GetThreadAtIndex(0)
-process.SetSelectedThread(thread0)
-i = 0
-found = False
-for f in thread0:
-# print("frame#%d %s" % (i, f.GetFunctionName()))
-if "MainLoop" in f.GetFunctionName():
-found = True
-thread0.SetSelectedFrame(i)
-if self.TraceOn():
-print("Found frame#%d for function 'MainLoop'" % i)
-break
-i += 1
-
-# Reset the stopwatch now.
-self.stopwatch.reset()
-for i in range(count):
-with self.stopwatch:
-# Disassemble the function.
-self.runCmd("disassemble -f")
Index: packages/Python/lldbsuite/test/benchmarks/disassembly/TestXcode41Vs42GDBDisassembly.py
===
--- packages/Python/lldbsuite/test/benchmarks/disassembly/TestXcode41Vs42GDBDisassembly.py
+++ packages/Python/lldbsuite/test/benchmarks/disassembly/TestXcode41Vs42GDBDisassembly.py
@@ -1,120 +0,0 @@
-"""Disassemble lldb's Driver::MainLoop() functions comparing Xcode 4.1 vs. 4.2's gdb."""
-
-from __future__ import print_function
-
-
-import os
-import sys
-import lldb
-from lldbsuite.test.decorators import *
-from lldbsuite.test.lldbbench import *
-from lldbsuite.test.lldbtest import *
-from lldbsuite.test import configuration
-from lldbsuite.test import lldbutil
-
-
-class XCode41Vs42GDBDisassembly(BenchBase):
-
-mydir = TestBase.compute_mydir(__file__)
-
-def setUp(self):
-BenchBase.setUp(self)
-self.gdb_41_exe = '/Xcode41/usr/bin/gdb'
-self.gdb_42_exe = '/Developer/usr/bin/gdb'
-self.exe = lldbtest_config.lldbExec
-self.function = 'Driver::MainLoop()'
-self.gdb_41_avg = None
-self.gdb_42_avg = None
-self.count = 5
-
-@benchmarks_test
-@no_debug_info_test
-@expectedFailureAll(
-oslist=["windows"],
-bugnumber="llvm.org/pr22274: need a pexpect replacement for windows")
-def test_run_41_then_42(self):
-"""Test disassembly on a large function with 4.1 vs. 4.2's gdb."""
-print()
-self.run_gdb_disassembly(
-self.gdb_41_exe,

[Lldb-commits] [PATCH] D55608: Make crashlog.py work or binaries with spaces in their names

[Greg Clayton via Phabricator via lldb-commits]

clayborg requested changes to this revision.
clayborg added inline comments.



Comment at: examples/python/crashlog.py:99
 image_regex_uuid = re.compile(
-'(0x[0-9a-fA-F]+)[- ]+(0x[0-9a-fA-F]+) +[+]?([^ ]+) 
+([^<]+)<([-0-9a-fA-F]+)> (.*)')
+'(0x[0-9a-fA-F]+)[- ]+(0x[0-9a-fA-F]+) +[+]?(.+?) +([0-9a-zA-Z_]+) 
+<([-0-9a-fA-F]+)> (.*)')
 image_regex_no_uuid = re.compile(

This regex doesn't work. Head to https://regex101.com/ and try it out with 
either:

```
   0x104591000 -0x1055cfff7 +llvm-dwarfdump (0) 
 /Users/USER/Documents/*/llvm-dwarfdump
0x7fff63f2 - 0x7fff63f77ff7  libc++.1.dylib (400.9.4) 
 /usr/lib/libc++.1.dylib
```

The old regex works



Comment at: examples/python/crashlog.py:101
 image_regex_no_uuid = re.compile(
-'(0x[0-9a-fA-F]+)[- ]+(0x[0-9a-fA-F]+) +[+]?([^ ]+) +([^/]+)/(.*)')
+'(0x[0-9a-fA-F]+)[- ]+(0x[0-9a-fA-F]+) +[+]?(.+?) +([0-9a-zA-Z_]+) 
+/(.*)')
 empty_line_regex = re.compile('^$')

This one doesn't seem to work either


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55608/new/

https://reviews.llvm.org/D55608



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

[Lldb-commits] [PATCH] D55718: [ARC] Basic support in gdb-remote process plugin

[Tatyana Krasnukha via Phabricator via lldb-commits]

tatyana-krasnukha created this revision.
tatyana-krasnukha added reviewers: clayborg, jasonmolenda.
tatyana-krasnukha added a project: LLDB.
Herald added subscribers: lldb-commits, mgorny.

Add ARC architecture (bare-metal) that can be debugged through an RSP-server.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D55718

Files:
  include/lldb/Core/Architecture.h
  include/lldb/Utility/ArchSpec.h
  source/API/SystemInitializerFull.cpp
  source/Plugins/Architecture/Arc/ArchitectureArc.cpp
  source/Plugins/Architecture/Arc/ArchitectureArc.h
  source/Plugins/Architecture/Arc/CMakeLists.txt
  source/Plugins/Architecture/CMakeLists.txt
  source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  source/Target/Platform.cpp
  source/Target/Target.cpp
  source/Target/Thread.cpp
  source/Utility/ArchSpec.cpp

Index: source/Utility/ArchSpec.cpp
===
--- source/Utility/ArchSpec.cpp
+++ source/Utility/ArchSpec.cpp
@@ -221,7 +221,8 @@
 {eByteOrderLittle, 4, 1, 1, llvm::Triple::kalimba, ArchSpec::eCore_kalimba4,
  "kalimba4"},
 {eByteOrderLittle, 4, 1, 1, llvm::Triple::kalimba, ArchSpec::eCore_kalimba5,
- "kalimba5"}};
+ "kalimba5"},
+{eByteOrderLittle, 4, 2, 4, llvm::Triple::arc, ArchSpec::eCore_arc, "arc"}};
 
 // Ensure that we have an entry in the g_core_definitions for each core. If you
 // comment out an entry above, you will need to comment out the corresponding
@@ -458,7 +459,9 @@
 {ArchSpec::eCore_kalimba4, llvm::ELF::EM_CSR_KALIMBA,
  llvm::Triple::KalimbaSubArch_v4, 0xu, 0xu}, // KALIMBA
 {ArchSpec::eCore_kalimba5, llvm::ELF::EM_CSR_KALIMBA,
- llvm::Triple::KalimbaSubArch_v5, 0xu, 0xu} // KALIMBA
+ llvm::Triple::KalimbaSubArch_v5, 0xu, 0xu}, // KALIMBA
+{ArchSpec::eCore_arc, llvm::ELF::EM_ARC_COMPACT2, LLDB_INVALID_CPUTYPE,
+ 0xu, 0xu } // ARC
 };
 
 static const ArchDefinition g_elf_arch_def = {
Index: source/Target/Thread.cpp
===
--- source/Target/Thread.cpp
+++ source/Target/Thread.cpp
@@ -2058,6 +2058,7 @@
 switch (machine) {
 case llvm::Triple::x86_64:
 case llvm::Triple::x86:
+case llvm::Triple::arc:
 case llvm::Triple::arm:
 case llvm::Triple::aarch64:
 case llvm::Triple::thumb:
Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -67,11 +67,11 @@
 
 Target::Arch::Arch(const ArchSpec &spec)
 : m_spec(spec),
-  m_plugin_up(PluginManager::CreateArchitectureInstance(spec)) {}
+  m_plugin_up(PluginManager::CreateArchitectureInstance(m_spec)) {}
 
 const Target::Arch& Target::Arch::operator=(const ArchSpec &spec) {
   m_spec = spec;
-  m_plugin_up = PluginManager::CreateArchitectureInstance(spec);
+  m_plugin_up = PluginManager::CreateArchitectureInstance(m_spec);
   return *this;
 }
 
@@ -1527,7 +1527,7 @@
   os_changed, os_ver_changed, env_changed);
 
 if (!arch_changed && !vendor_changed && !os_changed && !env_changed)
-  replace_local_arch = false;
+  replace_local_arch = arch_spec.GetFlags() != m_arch.GetSpec().GetFlags();
   }
 }
   }
Index: source/Target/Platform.cpp
===
--- source/Target/Platform.cpp
+++ source/Target/Platform.cpp
@@ -1869,6 +1869,12 @@
   size_t trap_opcode_size = 0;
 
   switch (arch.GetMachine()) {
+  case llvm::Triple::arc: {
+static const uint8_t g_hex_opcode[] = { 0xff, 0x7f };
+trap_opcode = g_hex_opcode;
+trap_opcode_size = sizeof(g_hex_opcode);
+  } break;
+
   case llvm::Triple::aarch64: {
 static const uint8_t g_aarch64_opcode[] = {0x00, 0x00, 0x20, 0xd4};
 trap_opcode = g_aarch64_opcode;
Index: source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
===
--- source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
+++ source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
@@ -622,6 +622,55 @@
   }
   break;
 
+case llvm::Triple::arc:
+  {
+for (auto ® : m_regs) {
+  if (strcmp(reg.name, "pc") == 0)
+reg.kinds[eRegisterKindGeneric] = LLDB_REGNUM_GENERIC_PC;
+  else if ((strcmp(reg.name, "fp") == 0) ||
+   (strcmp(reg.name, "r27") == 0))
+reg.kinds[eRegisterKindGeneric] = LLDB_REGNUM_GENERIC_FP;
+  else if ((strcmp(reg.name, "sp") == 0) ||
+   (strcmp(reg.name, "r28") == 0))
+reg.kinds[eRegisterKindGeneric] = LLDB_REGNUM_GENERIC_SP;
+  else if ((strcmp(reg.name, "blink") == 0) ||
+   (strcmp(reg.name, "r31") == 0))
+ 

[Lldb-commits] [PATCH] D55724: [ARC] Add SystemV ABI

[Tatyana Krasnukha via Phabricator via lldb-commits]

tatyana-krasnukha created this revision.
tatyana-krasnukha added a reviewer: clayborg.
tatyana-krasnukha added a project: LLDB.
Herald added subscribers: lldb-commits, teemperor, mgorny.

Repository:
  rLLDB LLDB

https://reviews.llvm.org/D55724

Files:
  source/API/SystemInitializerFull.cpp
  source/Plugins/ABI/CMakeLists.txt
  source/Plugins/ABI/SysV-arc/ABISysV_arc.cpp
  source/Plugins/ABI/SysV-arc/ABISysV_arc.h
  source/Plugins/ABI/SysV-arc/CMakeLists.txt

Index: source/Plugins/ABI/SysV-arc/CMakeLists.txt
===
--- source/Plugins/ABI/SysV-arc/CMakeLists.txt
+++ source/Plugins/ABI/SysV-arc/CMakeLists.txt
@@ -0,0 +1,11 @@
+add_lldb_library(lldbPluginABISysV_arc PLUGIN
+  ABISysV_arc.cpp
+
+  LINK_LIBS
+lldbCore
+lldbSymbol
+lldbTarget
+lldbPluginProcessUtility
+  LINK_COMPONENTS
+Support
+  )
Index: source/Plugins/ABI/SysV-arc/ABISysV_arc.h
===
--- source/Plugins/ABI/SysV-arc/ABISysV_arc.h
+++ source/Plugins/ABI/SysV-arc/ABISysV_arc.h
@@ -0,0 +1,103 @@
+//===-- ABISysV_arc.h -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef liblldb_ABISysV_arc_h_
+#define liblldb_ABISysV_arc_h_
+
+// C Includes
+// C++ Includes
+// Other libraries and framework includes
+// Project includes
+#include "lldb/Target/ABI.h"
+#include "lldb/lldb-private.h"
+
+class ABISysV_arc : public lldb_private::ABI {
+public:
+  ~ABISysV_arc() override = default;
+
+  size_t GetRedZoneSize() const override;
+
+  bool PrepareTrivialCall(lldb_private::Thread &thread, lldb::addr_t sp,
+  lldb::addr_t functionAddress,
+  lldb::addr_t returnAddress,
+  llvm::ArrayRef args) const override;
+
+  // Special thread plan for GDB style non-jit function calls.
+  bool
+  PrepareTrivialCall(lldb_private::Thread &thread, lldb::addr_t sp,
+ lldb::addr_t functionAddress, lldb::addr_t returnAddress,
+ llvm::Type &prototype,
+ llvm::ArrayRef args) const override;
+
+  bool GetArgumentValues(lldb_private::Thread &thread,
+ lldb_private::ValueList &values) const override;
+
+  lldb_private::Status
+  SetReturnValueObject(lldb::StackFrameSP &frame_sp,
+   lldb::ValueObjectSP &new_value) override;
+
+  lldb::ValueObjectSP
+  GetReturnValueObjectImpl(lldb_private::Thread &thread,
+   lldb_private::CompilerType &type) const override;
+
+  // Specialized to work with llvm IR types.
+  lldb::ValueObjectSP GetReturnValueObjectImpl(lldb_private::Thread &thread,
+   llvm::Type &type) const override;
+
+  bool
+  CreateFunctionEntryUnwindPlan(lldb_private::UnwindPlan &unwind_plan) override;
+
+  bool CreateDefaultUnwindPlan(lldb_private::UnwindPlan &unwind_plan) override;
+
+  bool RegisterIsVolatile(const lldb_private::RegisterInfo *reg_info) override;
+
+  bool CallFrameAddressIsValid(lldb::addr_t cfa) override {
+// Stack call frame address must be 4 byte aligned.
+return (cfa & 0x3ull) == 0;
+  }
+
+  bool CodeAddressIsValid(lldb::addr_t pc) override {
+// Code addresse must be 2 byte aligned.
+return (pc & 1ull) == 0;
+  }
+
+  const lldb_private::RegisterInfo *
+  GetRegisterInfoArray(uint32_t &count) override;
+
+  //--
+  // Static Functions
+  //--
+
+  static void Initialize();
+
+  static void Terminate();
+
+  static lldb::ABISP CreateInstance(lldb::ProcessSP process_sp,
+const lldb_private::ArchSpec &arch);
+
+  static lldb_private::ConstString GetPluginNameStatic();
+
+  //--
+  // PluginInterface protocol
+  //--
+
+  lldb_private::ConstString GetPluginName() override;
+
+  uint32_t GetPluginVersion() override;
+
+protected:
+  lldb::ValueObjectSP
+  GetReturnValueObjectSimple(lldb_private::Thread &thread,
+ lldb_private::CompilerType &ast_type) const;
+
+private:
+  using lldb_private::ABI::ABI; // Call CreateInstance instead.
+};
+
+#endif // liblldb_ABISysV_arc_h_
Index: source/Plugins/ABI/SysV-arc/ABISysV_arc.cpp
===
--- source/Plugins/ABI/SysV-arc/ABISysV_arc.cpp
+++ source/Plugins/ABI/SysV-arc/ABISysV_arc.cpp
@@ -0,0 +1,512 @@
+//===-- ABISysV_arc.cpp ---*-

[Lldb-commits] [lldb] r349208 - Update a comment according to r255360 "Remove -r and -R options from dotest.py"

[Tatyana Krasnukha via lldb-commits]

Author: tkrasnukha
Date: Fri Dec 14 15:02:41 2018
New Revision: 349208

URL: http://llvm.org/viewvc/llvm-project?rev=349208&view=rev
Log:
Update a comment according to r255360 "Remove -r and -R options from dotest.py"

Modified:
lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py?rev=349208&r1=349207&r2=349208&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Fri Dec 14 15:02:41 
2018
@@ -72,8 +72,7 @@ from lldbsuite.support import encoded_fi
 from lldbsuite.support import funcutils
 
 # See also dotest.parseOptionsAndInitTestdirs(), where the environment 
variables
-# LLDB_COMMAND_TRACE and LLDB_DO_CLEANUP are set from '-t' and '-r dir'
-# options.
+# LLDB_COMMAND_TRACE is set from '-t' option.
 
 # By default, traceAlways is False.
 if "LLDB_COMMAND_TRACE" in os.environ and os.environ[


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

[Lldb-commits] [PATCH] D55727: Add "dump" command as a custom "process plugin" subcommand when ProcessMinidump is used.

[Greg Clayton via Phabricator via lldb-commits]

clayborg created this revision.
clayborg added reviewers: zturner, labath, lemo.

Each process plug-in can create its own custom commands. I figured it would be 
nice to be able to dump things from the minidump file from the lldb command 
line, so I added the start of the some custom commands.

Currently you can dump:

- minidump stream directory
- all linux specifc streams, most of which are strings
- each linux stream individually if desired, or all with --linux

The idea is we can expand the command set to dump more things, search for data 
in the core file, and much more. This patch gets us started.


https://reviews.llvm.org/D55727

Files:
  source/Plugins/Process/minidump/MinidumpParser.cpp
  source/Plugins/Process/minidump/MinidumpParser.h
  source/Plugins/Process/minidump/MinidumpTypes.h
  source/Plugins/Process/minidump/ProcessMinidump.cpp
  source/Plugins/Process/minidump/ProcessMinidump.h

Index: source/Plugins/Process/minidump/ProcessMinidump.h
===
--- source/Plugins/Process/minidump/ProcessMinidump.h
+++ source/Plugins/Process/minidump/ProcessMinidump.h
@@ -49,6 +49,8 @@
   bool CanDebug(lldb::TargetSP target_sp,
 bool plugin_specified_by_name) override;
 
+  CommandObject *GetPluginCommandObject() override;
+
   Status DoLoadCore() override;
 
   DynamicLoader *GetDynamicLoader() override { return nullptr; }
@@ -104,6 +106,7 @@
   FileSpec m_core_file;
   llvm::ArrayRef m_thread_list;
   const MinidumpExceptionStream *m_active_exception;
+  lldb::CommandObjectSP m_command_sp;
   bool m_is_wow64;
 };
 
Index: source/Plugins/Process/minidump/ProcessMinidump.cpp
===
--- source/Plugins/Process/minidump/ProcessMinidump.cpp
+++ source/Plugins/Process/minidump/ProcessMinidump.cpp
@@ -10,10 +10,17 @@
 #include "ProcessMinidump.h"
 #include "ThreadMinidump.h"
 
+#include "lldb/Core/DumpDataExtractor.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/Section.h"
+#include "lldb/Interpreter/CommandInterpreter.h"
+#include "lldb/Interpreter/CommandObject.h"
+#include "lldb/Interpreter/CommandObjectMultiword.h"
+#include "lldb/Interpreter/CommandReturnObject.h"
+#include "lldb/Interpreter/OptionArgParser.h"
+#include "lldb/Interpreter/OptionGroupBoolean.h"
 #include "lldb/Target/JITLoaderList.h"
 #include "lldb/Target/MemoryRegionInfo.h"
 #include "lldb/Target/SectionLoadList.h"
@@ -398,3 +405,242 @@
   }
   return *m_jit_loaders_ap;
 }
+
+class CommandObjectProcessMinidumpDump : public CommandObjectParsed {
+private:
+  OptionGroupOptions m_option_group;
+  OptionGroupBoolean m_dump_all;
+  OptionGroupBoolean m_dump_directory;
+  OptionGroupBoolean m_dump_linux_cpuinfo;
+  OptionGroupBoolean m_dump_linux_proc_status;
+  OptionGroupBoolean m_dump_linux_lsb_release;
+  OptionGroupBoolean m_dump_linux_cmdline;
+  OptionGroupBoolean m_dump_linux_environ;
+  OptionGroupBoolean m_dump_linux_auxv;
+  OptionGroupBoolean m_dump_linux_maps;
+  OptionGroupBoolean m_dump_linux_proc_stat;
+  OptionGroupBoolean m_dump_linux_proc_uptime;
+  OptionGroupBoolean m_dump_linux_proc_fd;
+  OptionGroupBoolean m_dump_linux_all;
+
+  void SetDefaultOptionsIfNoneAreSet() {
+if (m_dump_all.GetOptionValue().GetCurrentValue() ||
+m_dump_linux_all.GetOptionValue().GetCurrentValue() ||
+m_dump_directory.GetOptionValue().GetCurrentValue() ||
+m_dump_linux_cpuinfo.GetOptionValue().GetCurrentValue() ||
+m_dump_linux_proc_status.GetOptionValue().GetCurrentValue() ||
+m_dump_linux_lsb_release.GetOptionValue().GetCurrentValue() ||
+m_dump_linux_cmdline.GetOptionValue().GetCurrentValue() ||
+m_dump_linux_environ.GetOptionValue().GetCurrentValue() ||
+m_dump_linux_auxv.GetOptionValue().GetCurrentValue() ||
+m_dump_linux_maps.GetOptionValue().GetCurrentValue() ||
+m_dump_linux_proc_stat.GetOptionValue().GetCurrentValue() ||
+m_dump_linux_proc_uptime.GetOptionValue().GetCurrentValue() ||
+m_dump_linux_proc_fd.GetOptionValue().GetCurrentValue())
+  return;
+// If no options were set, then dump everything
+m_dump_all.GetOptionValue().SetCurrentValue(true);
+  }
+  bool DumpAll() const {
+return m_dump_all.GetOptionValue().GetCurrentValue();
+  }
+  bool DumpDirectory() const {
+return DumpAll() ||
+m_dump_directory.GetOptionValue().GetCurrentValue();
+  }
+  bool DumpLinux() const {
+return DumpAll() || m_dump_linux_all.GetOptionValue().GetCurrentValue();
+  }
+  bool DumpLinuxCPUInfo() const {
+return DumpLinux() ||
+m_dump_linux_cpuinfo.GetOptionValue().GetCurrentValue();
+  }
+  bool DumpLinuxProcStatus() const {
+return DumpLinux() ||
+m_dump_linux_proc_status.GetOptionValue().GetCurrentValue();
+  }
+  bool DumpLinuxProcStat() const {
+return DumpLinux() ||
+m

[Lldb-commits] [PATCH] D55631: Delay replacing the process till after we've finalized it

[Jim Ingham via Phabricator via lldb-commits]

jingham updated this revision to Diff 178306.
jingham added a comment.

This is better.  Instead of just finalizing, I call DeleteCurrentProcess.  All 
the plugins that implement DebugProcess actually call DeleteCurrentProcess, so 
this just makes sure it happens before we drop our (potentially last) reference 
to the process sp.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55631/new/

https://reviews.llvm.org/D55631

Files:
  source/Target/Target.cpp


Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -2864,22 +2864,15 @@
   log->Printf("Target::%s asking the platform to debug the process",
   __FUNCTION__);
 
-// Get a weak pointer to the previous process if we have one
-ProcessWP process_wp;
-if (m_process_sp)
-  process_wp = m_process_sp;
+// If there was a previous process, delete it before we make the new one.
+// One subtle point, we delete the process before we release the reference
+// to m_process_sp.  That way even if we are the last owner, the process
+// will get Finalized before it gets destroyed.
+DeleteCurrentProcess();
+
 m_process_sp =
 GetPlatform()->DebugProcess(launch_info, debugger, this, error);
 
-// Cleanup the old process since someone might still have a strong
-// reference to this process and we would like to allow it to cleanup as
-// much as it can without the object being destroyed. We try to lock the
-// shared pointer and if that works, then someone else still has a strong
-// reference to the process.
-
-ProcessSP old_process_sp(process_wp.lock());
-if (old_process_sp)
-  old_process_sp->Finalize();
   } else {
 if (log)
   log->Printf("Target::%s the platform doesn't know how to debug a "


Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -2864,22 +2864,15 @@
   log->Printf("Target::%s asking the platform to debug the process",
   __FUNCTION__);
 
-// Get a weak pointer to the previous process if we have one
-ProcessWP process_wp;
-if (m_process_sp)
-  process_wp = m_process_sp;
+// If there was a previous process, delete it before we make the new one.
+// One subtle point, we delete the process before we release the reference
+// to m_process_sp.  That way even if we are the last owner, the process
+// will get Finalized before it gets destroyed.
+DeleteCurrentProcess();
+
 m_process_sp =
 GetPlatform()->DebugProcess(launch_info, debugger, this, error);
 
-// Cleanup the old process since someone might still have a strong
-// reference to this process and we would like to allow it to cleanup as
-// much as it can without the object being destroyed. We try to lock the
-// shared pointer and if that works, then someone else still has a strong
-// reference to the process.
-
-ProcessSP old_process_sp(process_wp.lock());
-if (old_process_sp)
-  old_process_sp->Finalize();
   } else {
 if (log)
   log->Printf("Target::%s the platform doesn't know how to debug a "
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D55727: Add "dump" command as a custom "process plugin" subcommand when ProcessMinidump is used.

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

This sounds like a good use-case for a lit / FileCheck test.  Could you add 
some simple tests that run lldb with -c on a static minidump with known 
information inside that we don't change, then run these commands and check the 
output?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55727/new/

https://reviews.llvm.org/D55727



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

[Lldb-commits] [lldb] r349211 - Fix the unittests for the move of Listener & Broadcaster

[Jim Ingham via lldb-commits]

Author: jingham
Date: Fri Dec 14 15:27:08 2018
New Revision: 349211

URL: http://llvm.org/viewvc/llvm-project?rev=349211&view=rev
Log:
Fix the unittests for the move of Listener & Broadcaster
from Core to Utility.

Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=349211&r1=349210&r2=349211&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Fri Dec 14 15:27:08 2018
@@ -3580,12 +3580,14 @@
2321F9421BDD343A00BA9A93 /* Utility */ = {
isa = PBXGroup;
children = (
+   23CB14E61D66CC0E00EDDDE1 /* BroadcasterTest.cpp 
*/,
7F94D7172040A13A006EE3EA /* CleanUpTest.cpp */,
23E2E5161D903689006F38BB /* ArchSpecTest.cpp */,
9A3D43C81F3150D200EB767C /* ConstStringTest.cpp 
*/,
AFA1B62B219E0ED900A8AB7E /* 
DataExtractorTest.cpp */,
23CB14FD1D66CD2400EDDDE1 /* FileSpecTest.cpp */,
8C3BD99F1EF5D1B50016C343 /* JSONTest.cpp */,
+   9A3D43E31F3237D500EB767C /* ListenerTest.cpp */,
9A3D43C71F3150D200EB767C /* LogTest.cpp */,
9A3D43CB1F3150D200EB767C /* NameMatchesTest.cpp 
*/,
23CB14E91D66CC0E00EDDDE1 /* ScalarTest.cpp */,
@@ -3745,10 +3747,8 @@
23CB14E51D66CBEB00EDDDE1 /* Core */ = {
isa = PBXGroup;
children = (
-   23CB14E61D66CC0E00EDDDE1 /* BroadcasterTest.cpp 
*/,
23CB14E71D66CC0E00EDDDE1 /* CMakeLists.txt */,
58A080B12112AB2200D5580F /* HighlighterTest.cpp 
*/,
-   9A3D43E31F3237D500EB767C /* ListenerTest.cpp */,
4F29D3CD21010F84003B549A /* MangledTest.cpp */,
4FBC04F3211A0F0F0015A814 /* 
RichManglingContextTest.cpp */,
9A3D43E11F3237D500EB767C /* 
StreamCallbackTest.cpp */,


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

[Lldb-commits] [PATCH] D55727: Add "dump" command as a custom "process plugin" subcommand when ProcessMinidump is used.

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

In D55727#1331843 , @zturner wrote:

> This sounds like a good use-case for a lit / FileCheck test.  Could you add 
> some simple tests that run lldb with -c on a static minidump with known 
> information inside that we don't change, then run these commands and check 
> the output?


Yep, I will custom produce some output. I have a minidump generator if you ever 
need something generated for a test.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55727/new/

https://reviews.llvm.org/D55727



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

[Lldb-commits] [PATCH] D55727: Add "dump" command as a custom "process plugin" subcommand when ProcessMinidump is used.

[Leonard Mosescu via Phabricator via lldb-commits]

lemo accepted this revision.
lemo added a comment.
This revision is now accepted and ready to land.

I love the idea of custom dump commands, thanks Greg.

The changes look good to me (I agree with Zach suggestion to add lit tests)




Comment at: source/Plugins/Process/minidump/MinidumpParser.cpp:706
+  }
+  return "???";
+}

use a more explicit text, ex "unknown stream type" ?



Comment at: source/Plugins/Process/minidump/ProcessMinidump.cpp:495
+public:
+#define INIT_BOOL(VAR, LONG, SHORT, DESC) \
+VAR(LLDB_OPT_SET_1, false, LONG, SHORT, DESC, false, true)

I'm not a fan of "embedded" macro definitions - it may suggests that they are 
scope bound why they are not. I'd move them above the class definition.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55727/new/

https://reviews.llvm.org/D55727



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

[Lldb-commits] [lldb] r349231 - A brief outline of the packets that need to be implemented

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Fri Dec 14 18:36:39 2018
New Revision: 349231

URL: http://llvm.org/viewvc/llvm-project?rev=349231&view=rev
Log:
A brief outline of the packets that need to be implemented
to write an lldb platform server that doesn't link against
LLDB.framework to be able to fully run the lldb testsuite
on a remote system.  The platform packets weren't covered 
in the existing lldb-gdb-remote.txt doc, so I wanted to 
jot them down in one place.

Added:
lldb/trunk/docs/lldb-platform-packets.txt

Added: lldb/trunk/docs/lldb-platform-packets.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/lldb-platform-packets.txt?rev=349231&view=auto
==
--- lldb/trunk/docs/lldb-platform-packets.txt (added)
+++ lldb/trunk/docs/lldb-platform-packets.txt Fri Dec 14 18:36:39 2018
@@ -0,0 +1,375 @@
+Here is a brief overview of the packets that an lldb platform server needs to 
implement
+for the lldb testsuite to be run on a remote target device/system.
+
+//--
+// QStartNoAckMode
+//
+// BRIEF
+//   A request to stop sending ACK packets for each properly formatted packet.
+//
+// EXAMPLE 
+//   A platform session will typically start like this:
+//
+//   receive: +$QStartNoAckMode#b0
+//   send:+   <-- ACKing the properly formatted QStartNoAckMode packet
+//   send:$OK#9a
+//   receive: +   <-- Our OK packet getting ACKed
+//
+//   ACK mode is now disabled.
+
+//--
+// qHostInfo
+//
+// BRIEF
+//   Describe the hardware and OS of the target system
+//
+// EXAMPLE
+//
+//  receive: qHostInfo
+//  send:
cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5;
+//
+//  All numbers are base 10, os_version is a string that will be parsed as 
major.minor.patch.
+
+
+//--
+// qGetWorkingDir
+//
+// BRIEF
+//   Get the current working directory of the platform stub in
+//   ASCII hex encoding.
+//
+// EXAMPLE
+// 
+//  receive: qGetWorkingDir
+//  send:
2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773
 
+
+
+
+//--
+// QSetWorkingDir:
+//
+// BRIEF
+//   Set the current working directory of the platform stub in
+//   ASCII hex encoding.
+//
+// EXAMPLE
+// 
+//  receive: 
QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773
 
+//  send:OK
+
+//--
+// qPlatform_mkdir:
+//
+// BRIEF
+//   Create a directory on the target system.
+//
+// EXAMPLE
+// 
+//  receive: qPlatform_mkdir:01fd,2f746d702f6131
+//  send:F0
+//
+//  request packet has the fields:
+// 1. mode bits in base 16
+// 2. file path in ascii-hex encoding
+//
+//  response is F followed by the return value of the mkdir() call,
+//  base 10 encoded.
+
+//--
+// qPlatform_shell:
+//
+// BRIEF
+//   Run a shell command on the target system, return the output.
+//
+// EXAMPLE
+// 
+//  receive: qPlatform_shell:6c73202f746d702f,000a
+//  send:F,0,0,
+//
+//  request packet has the fields:
+// 1. shell command ascii-hex encoded
+// 2. timeout 
+// 3. {optional} working directory
+//
+//  Response is F followed by the return value of the command (base 16),
+//  followed by a another number, followed by the output of the command
+/   in binary-escaped-data encoding.
+
+//--
+// qLaunchGDBServer
+//
+// BRIEF
+//   Start a gdbserver process (gdbserver, debugserver, lldb-server)
+//   on the target system.
+//
+// EXAMPLE
+// 
+//  receive: qLaunchGDBServer;host:;
+//  send:pid:1337;port:43001;
+//
+//  request packet hostname field is not ascii-hex encoded.  Hopefully
+//  hostnames don't have $ or # characters in them.
+//
+//  response to the packet is the pid of the newly launched gdbserver,
+//  and the port it is listening for a connection on.
+//
+//  When the testsuite is running, lldb may use the pid to kill off a 
+//  debugserver that doesn't seem to be responding, etc.
+
+//--
+// qKillSpawnedProcess:
+//
+// BRIEF
+//   Kill a process running on the target system.
+//
+// EXAMPLE
+// 
+//  receive: qKillSpawnedProcess:1337
+//  send:OK
+//
+//  The request packet has the process ID in base 10.
+
+//--
+// qProcessInfoPID:
+//
+// BRIEF
+/

[Lldb-commits] [lldb] r349232 - Ah, forgot qModuleInfo. Need to look that one up

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Fri Dec 14 18:51:01 2018
New Revision: 349232

URL: http://llvm.org/viewvc/llvm-project?rev=349232&view=rev
Log:
Ah, forgot qModuleInfo.  Need to look that one up
and finish filling this in.

Modified:
lldb/trunk/docs/lldb-platform-packets.txt

Modified: lldb/trunk/docs/lldb-platform-packets.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/lldb-platform-packets.txt?rev=349232&r1=349231&r2=349232&view=diff
==
--- lldb/trunk/docs/lldb-platform-packets.txt (original)
+++ lldb/trunk/docs/lldb-platform-packets.txt Fri Dec 14 18:51:01 2018
@@ -30,6 +30,17 @@ for the lldb testsuite to be run on a re
 //
 //  All numbers are base 10, os_version is a string that will be parsed as 
major.minor.patch.
 
+//--
+// qModuleInfo
+//
+// BRIEF
+//   Report information about a binary on the target system
+//
+// EXAMPLE
+//  receive: qModuleInfo:2f62696e2f6c73;
+//
+// FIXME finish this packet description, v. 
GDBRemoteCommunicationServerCommon::Handle_qModuleInfo
+
 
 //--
 // qGetWorkingDir


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