date:20190916

[Lldb-commits] [PATCH] D67520: Add pretty printing of Clang "bitfield" enums

2019-09-16 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

This looks like a really useful feature. The code seems fine, but I am 
wondering if we should really bail out when encountering a zero enumerator. It 
is not uncommon to use a special enumerator to mean "none of the above". Lldb 
does that occasionally (eEmulateInstructionOptionNone), and other APIs do that 
too (PROT_NONE, PROT_READ, PROT_WRITE, PROT_EXEC in mmap(2) for instance). I am 
guessing this practice is even more common for "class" enums, as those can't be 
implicitly constructed from integer constants.

I think it would be useful to add one or two tests with enum types where this 
heuristic does not kick in. Like a type which has a two-bit enumerator which is 
not covered by previous enumerators, or (if you decide to keep the current 
behavior) a type with a zero enumerator.


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

https://reviews.llvm.org/D67520



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

[Lldb-commits] [PATCH] D67520: Add pretty printing of Clang "bitfield" enums

2019-09-16 Thread Fangrui Song via Phabricator via lldb-commits

MaskRay added inline comments.



Comment at: source/Symbol/ClangASTContext.cpp:9529
+  // in `enum {A, B, ALL = A|B }` we visit ALL first.
+  std::stable_sort(
+  values.begin(), values.end(), [](const auto &a, const auto &b) {

You can simply sort by magnitude and iterating the elements from the largest to 
the smallest.


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

https://reviews.llvm.org/D67520



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

[Lldb-commits] [PATCH] D67523: [Reproducer] Move GDB Remote Packet into Utility. (NFC)

2019-09-16 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

*Maybe* this is fine for now, but I also don't like moving the gdb-remote 
reproducer stuff out of the gdb plugin. If you want an inspection command to 
access those (which sounds like a useful thing btw), then the right way to 
handle that would be to have some sort of an abstraction/plugin mechanism for 
various reproducers. For instance, the reproducers could register themselves 
somewhere (if they don't do that already), so we get a list of all of them, 
similar to how we handle "plugins" now. Then the inspection command could 
iterate over that list and ask each reproducer component to do its thing. This 
may be clunky, or it may not, depending on what exactly this "thing" is.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D67523



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

[Lldb-commits] [PATCH] D67472: [Target] Move InferiorCall to Process

2019-09-16 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

cool


Repository:
  rL LLVM

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

https://reviews.llvm.org/D67472



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

[Lldb-commits] [lldb] r371962 - [test] Add -z separate-code to fix tests that ae sensitive to exact addresses after r371958

2019-09-16 Thread Fangrui Song via lldb-commits

Author: maskray
Date: Mon Sep 16 00:52:30 2019
New Revision: 371962

URL: http://llvm.org/viewvc/llvm-project?rev=371962&view=rev
Log:
[test] Add -z separate-code to fix tests that ae sensitive to exact addresses 
after r371958

Modified:
lldb/trunk/lit/SymbolFile/DWARF/debug-types-address-ranges.s
lldb/trunk/lit/SymbolFile/DWARF/dir-separator-no-comp-dir-relative-name.s
lldb/trunk/lit/SymbolFile/DWARF/dir-separator-no-comp-dir.s
lldb/trunk/lit/SymbolFile/DWARF/dir-separator-posix.s
lldb/trunk/lit/SymbolFile/DWARF/dir-separator-windows.s
lldb/trunk/lit/SymbolFile/DWARF/find-inline-method.s

Modified: lldb/trunk/lit/SymbolFile/DWARF/debug-types-address-ranges.s
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/DWARF/debug-types-address-ranges.s?rev=371962&r1=371961&r2=371962&view=diff
==
--- lldb/trunk/lit/SymbolFile/DWARF/debug-types-address-ranges.s (original)
+++ lldb/trunk/lit/SymbolFile/DWARF/debug-types-address-ranges.s Mon Sep 16 
00:52:30 2019
@@ -7,7 +7,7 @@
 # REQUIRES: lld, x86
 
 # RUN: llvm-mc -dwarf-version=5 -triple x86_64-pc-linux %s -filetype=obj >%t.o
-# RUN: ld.lld %t.o -o %t -image-base=0x47000
+# RUN: ld.lld %t.o -o %t -image-base=0x47000 -z separate-code
 # RUN: %lldb %t -o "image lookup -a 0x48000 -v" -o exit | FileCheck %s
 
 # CHECK:   CompileUnit: id = {0x0001}, file = "/tmp/a.cc", language = "c++"

Modified: 
lldb/trunk/lit/SymbolFile/DWARF/dir-separator-no-comp-dir-relative-name.s
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/DWARF/dir-separator-no-comp-dir-relative-name.s?rev=371962&r1=371961&r2=371962&view=diff
==
--- lldb/trunk/lit/SymbolFile/DWARF/dir-separator-no-comp-dir-relative-name.s 
(original)
+++ lldb/trunk/lit/SymbolFile/DWARF/dir-separator-no-comp-dir-relative-name.s 
Mon Sep 16 00:52:30 2019
@@ -5,7 +5,7 @@
 # REQUIRES: lld, x86
 
 # RUN: llvm-mc -triple x86_64-pc-linux %s -filetype=obj > %t.o
-# RUN: ld.lld %t.o -o %t
+# RUN: ld.lld %t.o -o %t -z separate-code
 # RUN: %lldb %t -s %S/Inputs/dir-separator-no-comp-dir-relative-name.lldbinit 
-o exit | FileCheck %s
 
 # CHECK-LABEL: image dump line-table a.c

Modified: lldb/trunk/lit/SymbolFile/DWARF/dir-separator-no-comp-dir.s
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/DWARF/dir-separator-no-comp-dir.s?rev=371962&r1=371961&r2=371962&view=diff
==
--- lldb/trunk/lit/SymbolFile/DWARF/dir-separator-no-comp-dir.s (original)
+++ lldb/trunk/lit/SymbolFile/DWARF/dir-separator-no-comp-dir.s Mon Sep 16 
00:52:30 2019
@@ -4,7 +4,7 @@
 # REQUIRES: lld, x86
 
 # RUN: llvm-mc -triple x86_64-pc-linux %s -filetype=obj > %t.o
-# RUN: ld.lld %t.o -o %t
+# RUN: ld.lld %t.o -o %t -z separate-code
 # RUN: %lldb %t -s %S/Inputs/dir-separator-windows.lldbinit -o exit | 
FileCheck %s
 
 # CHECK-LABEL: image dump line-table a.c

Modified: lldb/trunk/lit/SymbolFile/DWARF/dir-separator-posix.s
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/DWARF/dir-separator-posix.s?rev=371962&r1=371961&r2=371962&view=diff
==
--- lldb/trunk/lit/SymbolFile/DWARF/dir-separator-posix.s (original)
+++ lldb/trunk/lit/SymbolFile/DWARF/dir-separator-posix.s Mon Sep 16 00:52:30 
2019
@@ -4,7 +4,7 @@
 # REQUIRES: lld, x86
 
 # RUN: llvm-mc -triple x86_64-pc-linux %s -filetype=obj > %t.o
-# RUN: ld.lld %t.o -o %t
+# RUN: ld.lld %t.o -o %t -z separate-code
 # RUN: %lldb %t -s %S/Inputs/dir-separator-posix.lldbinit -o exit | FileCheck 
%s
 
 # CHECK-LABEL: image dump line-table a.c

Modified: lldb/trunk/lit/SymbolFile/DWARF/dir-separator-windows.s
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/DWARF/dir-separator-windows.s?rev=371962&r1=371961&r2=371962&view=diff
==
--- lldb/trunk/lit/SymbolFile/DWARF/dir-separator-windows.s (original)
+++ lldb/trunk/lit/SymbolFile/DWARF/dir-separator-windows.s Mon Sep 16 00:52:30 
2019
@@ -4,7 +4,7 @@
 # REQUIRES: lld, x86
 
 # RUN: llvm-mc -triple x86_64-pc-linux %s -filetype=obj > %t.o
-# RUN: ld.lld %t.o -o %t
+# RUN: ld.lld %t.o -o %t -z separate-code
 # RUN: %lldb %t -s %S/Inputs/dir-separator-windows.lldbinit -o exit | 
FileCheck %s
 
 # CHECK-LABEL: image dump line-table a.c

Modified: lldb/trunk/lit/SymbolFile/DWARF/find-inline-method.s
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/DWARF/find-inline-method.s?rev=371962&r1=371961&r2=371962&view=diff
==
--- lldb/trunk/lit/SymbolFile/DWARF/find-inline-method.s (original)
+++ lldb/trunk/lit/SymbolFile/DWARF/find-inline-method.s Mon Sep 16 00:52:30 
2019
@@ -1,7 +1,7 @@
 # REQUIRES:

[Lldb-commits] [PATCH] D67347: [Windows] Use information from the PE32 exceptions directory to construct unwind plans

2019-09-16 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

Sorry for the delay, I was OOO. I haven't yet read through all of the 
discussion, but I wanted to plug into this part.

In D67347#1669877 , @aleksandr.urakov 
wrote:

> But there is one more reason that makes it very difficult to just create 
> `PECallFrameInfo` in `UnwindTable` like we do with `DWARFCallFrameInfo`: 
> `PECallFrameInfo` is coupled very tight with `ObjectFilePECOFF` and can't 
> work over plain `ObjectFile`. First of all, it uses several functions for 
> work with relative virtual addresses (RVA), and they are implemented with the 
> use of `ObjectFilePECOFF`'s private variable `m_image_base` (however, may be 
> it is possible to implement these methods over the `ObjectFile` interface, 
> I'm not sure about that). The second, it requires information about exception 
> directory location, but it is an inner mechanics of `ObjectFilePECOFF`. So 
> its relations with `ObjectFilePECOFF` are not the same as between 
> `DWARFCallFrameInfo` and ELF or Mach-O.


PE m_image_base is already available through generic object file interfaces. 
You can access it as obj_file->GetBaseAddress().GetFileAddress(). This is the 
same way as the Breakpad symbol file plugin does it. As for the location of the 
exception directory, it sounds like it would not be too horrendous to have the 
PE plugin parse that and expose this bit as a special section (with it's own 
special section type etc.). Then, we could (hopefully) write the PE unwind 
parser in a way which does not depend on object file internals, similar to how 
the eh_frame parser does it.

That said, there are two reasons I am not 100% in favour of that idea:

- the current location of the unwind parsers (source/Symbol) seems pretty weird 
to me. The code in this folder already does a lot of stuff, and most of it has 
nothing to do with unwinding. So, shoving more unwinding code there seems 
suboptimal. If we go down that path, I would propose we create a new folder 
(source/Unwind ?) and put the unwind parsers there.
- even with a separate "unwind" folder, it seems slightly weird to have formats 
which are clearly specific to one {symbol|object}file be in a generic place. I 
am here mostly thinking of more "exotic" formats like breakpad. While it would 
be possible (and I am happy to do that) to refactor the breakpad parser to work 
in this way, in does not seem completely optimal to me. That's why I would 
still be in favour of some "plugin" mechanism, where unwind formats which are 
definitely tied to some kind of a file format be implemented there. Then the 
more generic formats could live in the generic place, and things like breakpad 
(and possibly PECOFF) could live inside their plugins.

(Overall, don't take my comments as a hard objection to anything. It's just an 
opinion that I am happy to be overridden on.)




Comment at: lldb/source/Plugins/ObjectFile/PECOFF/PECallFrameInfo.cpp:15
+static const T *TypedRead(const DataExtractor &data_extractor, offset_t 
&offset, offset_t size = sizeof(T)) {
+  return static_cast(data_extractor.GetData(&offset, size));
+}

aleksandr.urakov wrote:
> labath wrote:
> > It doesn't look like this will do the right thing in if host endianness 
> > differs from the target. You should use GetMaxU64 instead. (or given that 
> > PE should be always little-endian (right?), you could also ditch the 
> > DataExtractor and read stuff by casting to llvm::support::ulittleXX_t. I 
> > believe that's how most of PECOFF parsing in llvm works.)
> I believe that this code is ok: it actually doesn't read a pointer to data, 
> it gets the data read from the file and interprets it like a structure of 
> type `T` (`GetData` returns just a pointer to the data buffer). I think it's 
> safe because `T` can be `RuntimeFunction`, `UnwindInfo` or `UnwindCode`, but 
> all these types are already using `ulittleXX_t` in their definitions.
Ah sorry. I missed that part. This seems fine then.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D67347



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

[Lldb-commits] [PATCH] D66654: 2/2: Process formatters in reverse-chronological order

2019-09-16 Thread Pavel Labath via Phabricator via lldb-commits

labath accepted this revision.
labath added a comment.

lgtm


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D66654



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

[Lldb-commits] [PATCH] D67589: Fix crash on SBCommandReturnObject & assignment

2019-09-16 Thread Pavel Labath via Phabricator via lldb-commits

labath added a reviewer: jingham.
labath added a comment.

+ Jim for SB API.

I ran into this quirk of SBCommandReturnObject a couple of weeks ago, and then 
ran away screaming.

I agree that this approach isn't nice, but probably there isn't a nice approach 
to this at this point. One possibility you could consider is storing a 
shared_ptr inside SBCommandRO and encoding the ownership into the 
deleter of the shared_ptr (regular deleter => owned, noop deleter => unowned).




Comment at: lldb/include/lldb/API/SBCommandReturnObject.h:24
+CommandReturnObject &
+SBCommandReturnObject_ref(lldb::SBCommandReturnObject &sb_cmd);
+}

Add a comment to explain the purpose of this function?



Comment at: 
lldb/packages/Python/lldbsuite/test/api/command-return-object/main.cpp:18
+result = subcommand(dbg, "help");
+result = result;
+if (!result.Succeeded())

Is that intentional? If so, why?



Comment at: 
lldb/packages/Python/lldbsuite/test/api/command-return-object/main.cpp:23
+  }
+} crasher;
+

This looks weird. Please use a separate declaration for the variable and the 
class.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D67589



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

[Lldb-commits] [PATCH] D67390: [LLDB][ELF] Load both, .symtab and .dynsym sections

2019-09-16 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

In D67390#1667270 , @kwk wrote:

> @labath how shall we go about this? We do have the situation that when you 
> lookup a symbol you might find it twice if it is in `.dynsym` and in 
> `.symtab`. Shall I adjust the test expectation to that or change my 
> implementation?

That's a good question (and another reason why I wanted this to be a separate 
patch). Since only two tests broke it does not seem like having some symbols 
twice does much harm. OTOH, having an identical symbol twice does seem like 
asking for trouble down the line. One possibility would be to restrict this 
merging to the gnu_debugdata case only. Another option would be to make the 
merging code smarter and avoid adding the symbol a second time if it has the 
same name and address. That would have the advantage of having the symbol just 
once in the common case, while still preserving the full information (in case 
the symbol tables were munged independently of the gnu_debugdata thingy).

Overall, I guess I would prefer the last solution (inserting only different 
symbols) unless that turns out to be difficult. In that case, I think just 
restricting this to gnu_debugdata is fine.

BTW, if you want, I think you can submit the rest of the gnu_debugdata changes 
without waiting for this, if you just adjust the test expectations to account 
for the fact that symtab+dynsym merging does not work (yet).

Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py:276
 matching=False,
-patterns=["1 match found"])
+patterns=["2 matches found"])

You can't do that because this will have only two matches on elf platforms. 
Since we don't really care about the number here. I suggest finding a string 
that can be grepped for, which does not depend on the number of matches (maybe 
just `a_function`).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67390

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

[Lldb-commits] [PATCH] D67390: [LLDB][ELF] Load both, .symtab and .dynsym sections

2019-09-16 Thread Konrad Wilhelm Kleine via Phabricator via lldb-commits

kwk added a comment.

In D67390#1671018 , @labath wrote:

> In D67390#1667270 , @kwk wrote:
>
> > @labath how shall we go about this? We do have the situation that when you 
> > lookup a symbol you might find it twice if it is in `.dynsym` and in 
> > `.symtab`. Shall I adjust the test expectation to that or change my 
> > implementation?
>
>
> That's a good question (and another reason why I wanted this to be a separate 
> patch). Since only two tests broke it does not seem like having some symbols 
> twice does much harm. OTOH, having an identical symbol twice does seem like 
> asking for trouble down the line. One possibility would be to restrict this 
> merging to the gnu_debugdata case only. Another option would be to make the 
> merging code smarter and avoid adding the symbol a second time if it has the 
> same name and address. That would have the advantage of having the symbol 
> just once in the common case, while still preserving the full information (in 
> case the symbol tables were munged independently of the gnu_debugdata thingy).
>
> Overall, I guess I would prefer the last solution (inserting only different 
> symbols) unless that turns out to be difficult. In that case, I think just 
> restricting this to gnu_debugdata is fine.


The crucial line is the following line in `ObjectFileELF::ParseSymbols()`:

  symtab->AddSymbol(dc_symbol);

If I change that to:

  symtab->FindSymbolsByNameAndAddress(dc_symbol.GetName(), 
dc_symbol.GetAddress(), indexVector)
  if (indexVector.empty()) {
symtab->AddSymbol(dc_symbol);
  }

is that the logic you have in mind? `FindSymbolsByNameAndAddress` I would need 
to implement.

> BTW, if you want, I think you can submit the rest of the gnu_debugdata 
> changes without waiting for this, if you just adjust the test expectations to 
> account for the fact that symtab+dynsym merging does not work (yet).

Let's wait first, okay?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67390



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

[Lldb-commits] [PATCH] D67390: [LLDB][ELF] Load both, .symtab and .dynsym sections

2019-09-16 Thread Greg Clayton via Phabricator via lldb-commits

clayborg added a comment.

In D67390#1671018 , @labath wrote:

> In D67390#1667270 , @kwk wrote:
>
> > @labath how shall we go about this? We do have the situation that when you 
> > lookup a symbol you might find it twice if it is in `.dynsym` and in 
> > `.symtab`. Shall I adjust the test expectation to that or change my 
> > implementation?
>
>
> That's a good question (and another reason why I wanted this to be a separate 
> patch). Since only two tests broke it does not seem like having some symbols 
> twice does much harm.

You should ensure that there aren't multiple symbols for the same address. 
Mach-o has this problem with the STAB symbols and the standard symbol table 
symbols. That plug-in will unique them into one using the STAB symbol table 
index as the lldb::user_id_t.

> OTOH, having an identical symbol twice does seem like asking for trouble down 
> the line. One possibility would be to restrict this merging to the 
> gnu_debugdata case only. Another option would be to make the merging code 
> smarter and avoid adding the symbol a second time if it has the same name and 
> address. That would have the advantage of having the symbol just once in the 
> common case, while still preserving the full information (in case the symbol 
> tables were munged independently of the gnu_debugdata thingy).

We really want to present the simplest and best view of the module to the the 
user. So please do only create one symbol, no matter how many sources we have.

> Overall, I guess I would prefer the last solution (inserting only different 
> symbols) unless that turns out to be difficult. In that case, I think just 
> restricting this to gnu_debugdata is fine.

Code to unique symbols isn't that hard to do during the symbol table parsing. 
Thought don't keep re-sorting the lldb_private::Symbol objects, just keep a 
side map that has file address to symbol name. I am guessing it will be easier 
than mach-o because there the different symbols have different info (STAB vs 
normal symbol table symbol) where as in ELF they should be the same.

> BTW, if you want, I think you can submit the rest of the gnu_debugdata 
> changes without waiting for this, if you just adjust the test expectations to 
> account for the fact that symtab+dynsym merging does not work (yet).

Love to see this fixed prior to checkin in possible

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67390

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

[Lldb-commits] [PATCH] D67390: [LLDB][ELF] Load both, .symtab and .dynsym sections

2019-09-16 Thread Greg Clayton via Phabricator via lldb-commits

clayborg added a comment.

In D67390#1671128 , @kwk wrote:

> In D67390#1671018 , @labath wrote:
>
> > In D67390#1667270 , @kwk wrote:
> >
> > > @labath how shall we go about this? We do have the situation that when 
> > > you lookup a symbol you might find it twice if it is in `.dynsym` and in 
> > > `.symtab`. Shall I adjust the test expectation to that or change my 
> > > implementation?
> >
> >
> > That's a good question (and another reason why I wanted this to be a 
> > separate patch). Since only two tests broke it does not seem like having 
> > some symbols twice does much harm. OTOH, having an identical symbol twice 
> > does seem like asking for trouble down the line. One possibility would be 
> > to restrict this merging to the gnu_debugdata case only. Another option 
> > would be to make the merging code smarter and avoid adding the symbol a 
> > second time if it has the same name and address. That would have the 
> > advantage of having the symbol just once in the common case, while still 
> > preserving the full information (in case the symbol tables were munged 
> > independently of the gnu_debugdata thingy).
> >
> > Overall, I guess I would prefer the last solution (inserting only different 
> > symbols) unless that turns out to be difficult. In that case, I think just 
> > restricting this to gnu_debugdata is fine.
>
>
> The crucial line is the following line in `ObjectFileELF::ParseSymbols()`:
>
>   symtab->AddSymbol(dc_symbol);
>
>
> If I change that to:
>
>   symtab->FindSymbolsByNameAndAddress(dc_symbol.GetName(), 
> dc_symbol.GetAddress(), indexVector)
>   if (indexVector.empty()) {
> symtab->AddSymbol(dc_symbol);
>   }
>


in mach-o plug-in we keep a std::map or something easier. We don't sort or 
search the current lldb_private::Symbol objects since they aren't sorted, nor 
are the name indexes created until we are done with adding all symbols. Can we 
use a side map that is just something like:

  std::map SymbolMapType;



> is that the logic you have in mind? `FindSymbolsByNameAndAddress` I would 
> need to implement.
> 
>> BTW, if you want, I think you can submit the rest of the gnu_debugdata 
>> changes without waiting for this, if you just adjust the test expectations 
>> to account for the fact that symtab+dynsym merging does not work (yet).
> 
> Let's wait first, okay?




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67390



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

[Lldb-commits] [PATCH] D67589: Fix crash on SBCommandReturnObject & assignment

2019-09-16 Thread Greg Clayton via Phabricator via lldb-commits

clayborg added inline comments.



Comment at: lldb/source/API/SBCommandInterpreter.cpp:165-172
+SBCommandReturnObject sb_return;
+std::swap(result, SBCommandReturnObject_ref(sb_return));
 SBCommandInterpreter sb_interpreter(&m_interpreter);
 SBDebugger debugger_sb(m_interpreter.GetDebugger().shared_from_this());
 bool ret = m_backend->DoExecute(
 debugger_sb, (char **)command.GetArgumentVector(), sb_return);
+std::swap(result, SBCommandReturnObject_ref(sb_return));

Could this code just create a local SBCommandReturnObject and then copy the 
CommandReturnObject back into "result"?

```
 bool DoExecute(Args &command, CommandReturnObject &result) override {
SBCommandReturnObject sb_return;
SBCommandInterpreter sb_interpreter(&m_interpreter);
SBDebugger debugger_sb(m_interpreter.GetDebugger().shared_from_this());
bool ret = m_backend->DoExecute(
debugger_sb, (char **)command.GetArgumentVector(), sb_return);
std::swap(result, sb_return.ref());
return ret;
}
```


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D67589



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

[Lldb-commits] [PATCH] D67520: Add pretty printing of Clang "bitfield" enums

2019-09-16 Thread Frederic Riss via Phabricator via lldb-commits

friss added a comment.

In D67520#1670880 , @labath wrote:

> This looks like a really useful feature. The code seems fine, but I am 
> wondering if we should really bail out when encountering a zero enumerator. 
> It is not uncommon to use a special enumerator to mean "none of the above". 
> Lldb does that occasionally (eEmulateInstructionOptionNone), and other APIs 
> do that too (PROT_NONE, PROT_READ, PROT_WRITE, PROT_EXEC in mmap(2) for 
> instance). I am guessing this practice is even more common for "class" enums, 
> as those can't be implicitly constructed from integer constants.
>
> I think it would be useful to add one or two tests with enum types where this 
> heuristic does not kick in. Like a type which has a two-bit enumerator which 
> is not covered by previous enumerators, or (if you decide to keep the current 
> behavior) a type with a zero enumerator.


I had looked at a few enums in LLVM before sending out the patch and decided to 
remove the "0" heuristic. I wrote the patch description with the new heuristic 
and then forgot to update the patch itself... I'm currently tracking down 
another regression that prevents Jim's use case from working, I'll refresh the 
patch with your comments addressed after I'm done with this.


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

https://reviews.llvm.org/D67520



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

[Lldb-commits] [PATCH] D67625: [lldb] [Process/gdb-remote] Fix defaulting signal to invalid in action list

2019-09-16 Thread Michał Górny via Phabricator via lldb-commits

mgorny created this revision.
mgorny added reviewers: labath, krytarowski.

Fix processing of "C" packet with signal for the whole process to
default signal value for action list to LLDB_INVALID_SIGNAL_NUMBER
rather than 0.


https://reviews.llvm.org/D67625

Files:
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp


Index: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1383,7 +1383,8 @@
   packet, "unexpected content after $C{signal-number}");
   }
 
-  ResumeActionList resume_actions(StateType::eStateRunning, 0);
+  ResumeActionList resume_actions(StateType::eStateRunning,
+  LLDB_INVALID_SIGNAL_NUMBER);
   Status error;
 
   // We have two branches: what to do if a continue thread is specified (in
@@ -3322,4 +3323,4 @@
 }
   }
   return result;
-}
\ No newline at end of file
+}


Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1383,7 +1383,8 @@
   packet, "unexpected content after $C{signal-number}");
   }
 
-  ResumeActionList resume_actions(StateType::eStateRunning, 0);
+  ResumeActionList resume_actions(StateType::eStateRunning,
+  LLDB_INVALID_SIGNAL_NUMBER);
   Status error;
 
   // We have two branches: what to do if a continue thread is specified (in
@@ -3322,4 +3323,4 @@
 }
   }
   return result;
-}
\ No newline at end of file
+}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67390: [LLDB][ELF] Load both, .symtab and .dynsym sections

2019-09-16 Thread Konrad Wilhelm Kleine via Phabricator via lldb-commits

kwk added a comment.

@clayborg what address is it exactly to store here `std::map SymbolMapType;`? As an example 
`dc_symbol.GetAddress().GetFileAddress()` is something that would work but as 
soon as we have minidebuginfo, then we might end having the same symbol coming 
from two different object files and so their address would still be different. 
Also do you want me to keep this map in `ObjectFileELF`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67390



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

[Lldb-commits] [PATCH] D67390: [LLDB][ELF] Load both, .symtab and .dynsym sections

2019-09-16 Thread Greg Clayton via Phabricator via lldb-commits

clayborg added a comment.

In D67390#1671463 , @kwk wrote:

> @clayborg what address is it exactly to store here `std::map ContString> SymbolMapType;`? As an example 
> `dc_symbol.GetAddress().GetFileAddress()` is something that would work but as 
> soon as we have minidebuginfo, then we might end having the same symbol 
> coming from two different object files and so their address would still be 
> different. Also do you want me to keep this map in `ObjectFileELF`?


We might need a private function on ObjectFileELF that takes an extra 
parameter. My idea would be something like:

  ... ObjectFileELF::GetSymtab() {
std::maphttps://reviews.llvm.org/D67390/new/

https://reviews.llvm.org/D67390



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

[Lldb-commits] [PATCH] D67390: [LLDB][ELF] Load both, .symtab and .dynsym sections

2019-09-16 Thread Greg Clayton via Phabricator via lldb-commits

clayborg added a comment.

In D67390#1671463 , @kwk wrote:

> @clayborg what address is it exactly to store here `std::map ContString> SymbolMapType;`? As an example 
> `dc_symbol.GetAddress().GetFileAddress()` is something that would work but as 
> soon as we have minidebuginfo, then we might end having the same symbol 
> coming from two different object files and so their address would still be 
> different. Also do you want me to keep this map in `ObjectFileELF`?

The file address should be sufficient for normal ELF files. When we have a 
minidebuginfo, we should almost to loading this as part of the ObjectFileELF 
that points to the minidebuginfo and parsing it as if it were part of that 
file. SymbolVendor used to exist to allow one view of an executable using 
multiple individual ObjectFile objects, but that got removed. So now it might 
be best to load the minidebuginfo file as an ObjectFileELF _just_ to access the 
data in the ".gnu_debugdata" and decompress it, and use that data to add to the 
symbol table of the current file? So the code would be:

  ObjectFileELF::GetSymtab() {
std::maphttps://reviews.llvm.org/D67390/new/

https://reviews.llvm.org/D67390

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

[Lldb-commits] [lldb] r372017 - [lldb][NFC] Make ApplyObjcCastHack less scary

2019-09-16 Thread Raphael Isemann via lldb-commits

Author: teemperor
Date: Mon Sep 16 11:02:21 2019
New Revision: 372017

URL: http://llvm.org/viewvc/llvm-project?rev=372017&view=rev
Log:
[lldb][NFC] Make ApplyObjcCastHack less scary

Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp

Modified: 
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp?rev=372017&r1=372016&r2=372017&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp 
(original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp 
Mon Sep 16 11:02:21 2019
@@ -313,17 +313,13 @@ void ClangUserExpression::ScanContext(Ex
 // count is not available, [myArray count] returns id, which can't be directly
 // cast to int without causing a clang error.
 static void ApplyObjcCastHack(std::string &expr) {
-#define OBJC_CAST_HACK_FROM "(int)["
-#define OBJC_CAST_HACK_TO "(int)(long long)["
+  std::string from = "(int)[";
+  std::string to = "(int)(long long)[";
 
-  size_t from_offset;
+  size_t offset;
 
-  while ((from_offset = expr.find(OBJC_CAST_HACK_FROM)) != expr.npos)
-expr.replace(from_offset, sizeof(OBJC_CAST_HACK_FROM) - 1,
- OBJC_CAST_HACK_TO);
-
-#undef OBJC_CAST_HACK_TO
-#undef OBJC_CAST_HACK_FROM
+  while ((offset = expr.find(from)) != expr.npos)
+expr.replace(offset, to.size(), to);
 }
 
 bool ClangUserExpression::SetupPersistentState(DiagnosticManager 
&diagnostic_manager,


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

[Lldb-commits] [lldb] r372018 - [lldb] Remove SetCount/ClearCount from Flags

2019-09-16 Thread Raphael Isemann via lldb-commits

Author: teemperor
Date: Mon Sep 16 11:02:49 2019
New Revision: 372018

URL: http://llvm.org/viewvc/llvm-project?rev=372018&view=rev
Log:
[lldb] Remove SetCount/ClearCount from Flags

Summary:
These functions are only used in tests where we should test the actual flag 
values instead of counting all bits for an approximate check.
Also these popcount implementation aren't very efficient and doesn't seem to be 
optimised to anything fast.

Reviewers: davide, JDevlieghere

Reviewed By: davide, JDevlieghere

Subscribers: abidh, JDevlieghere, lldb-commits

Tags: #lldb

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

Modified:
lldb/trunk/include/lldb/Utility/Flags.h
lldb/trunk/unittests/Utility/FlagsTest.cpp

Modified: lldb/trunk/include/lldb/Utility/Flags.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/Flags.h?rev=372018&r1=372017&r2=372018&view=diff
==
--- lldb/trunk/include/lldb/Utility/Flags.h (original)
+++ lldb/trunk/include/lldb/Utility/Flags.h Mon Sep 16 11:02:49 2019
@@ -121,32 +121,6 @@ public:
   /// \b true if \a bit is 0, \b false otherwise.
   bool IsClear(ValueType bit) const { return (m_flags & bit) == 0; }
 
-  /// Get the number of zero bits in \a m_flags.
-  ///
-  /// \return
-  /// The number of bits that are set to 0 in the current flags.
-  size_t ClearCount() const {
-size_t count = 0;
-for (ValueType shift = 0; shift < sizeof(ValueType) * 8; ++shift) {
-  if ((m_flags & (1u << shift)) == 0)
-++count;
-}
-return count;
-  }
-
-  /// Get the number of one bits in \a m_flags.
-  ///
-  /// \return
-  /// The number of bits that are set to 1 in the current flags.
-  size_t SetCount() const {
-size_t count = 0;
-for (ValueType mask = m_flags; mask; mask >>= 1) {
-  if (mask & 1u)
-++count;
-}
-return count;
-  }
-
 protected:
   ValueType m_flags; ///< The flags.
 };

Modified: lldb/trunk/unittests/Utility/FlagsTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Utility/FlagsTest.cpp?rev=372018&r1=372017&r2=372018&view=diff
==
--- lldb/trunk/unittests/Utility/FlagsTest.cpp (original)
+++ lldb/trunk/unittests/Utility/FlagsTest.cpp Mon Sep 16 11:02:49 2019
@@ -30,19 +30,18 @@ TEST(Flags, Reset) {
   Flags f;
   f.Reset(0x3);
   EXPECT_EQ(0x3U, f.Get());
-  EXPECT_EQ(2U, f.SetCount());
 }
 
 TEST(Flags, Clear) {
   Flags f;
   f.Reset(0x3);
-  EXPECT_EQ(2U, f.SetCount());
+  EXPECT_EQ(0x3U, f.Get());
 
   f.Clear(0x5);
-  EXPECT_EQ(1U, f.SetCount());
+  EXPECT_EQ(0x2U, f.Get());
 
   f.Clear();
-  EXPECT_EQ(0U, f.SetCount());
+  EXPECT_EQ(0x0U, f.Get());
 }
 
 TEST(Flags, AllSet) {
@@ -162,37 +161,3 @@ TEST(Flags, IsClear) {
   EXPECT_TRUE(f.IsClear(eFlag0));
   EXPECT_TRUE(f.IsClear(eFlag1));
 }
-
-TEST(Flags, ClearCount) {
-  Flags f;
-  EXPECT_EQ(32U, f.ClearCount());
-
-  f.Set(eFlag0);
-  EXPECT_EQ(31U, f.ClearCount());
-
-  f.Set(eFlag0);
-  EXPECT_EQ(31U, f.ClearCount());
-
-  f.Set(eFlag1);
-  EXPECT_EQ(30U, f.ClearCount());
-
-  f.Set(eAllFlags);
-  EXPECT_EQ(29U, f.ClearCount());
-}
-
-TEST(Flags, SetCount) {
-  Flags f;
-  EXPECT_EQ(0U, f.SetCount());
-
-  f.Set(eFlag0);
-  EXPECT_EQ(1U, f.SetCount());
-
-  f.Set(eFlag0);
-  EXPECT_EQ(1U, f.SetCount());
-
-  f.Set(eFlag1);
-  EXPECT_EQ(2U, f.SetCount());
-
-  f.Set(eAllFlags);
-  EXPECT_EQ(3U, f.SetCount());
-}


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

[Lldb-commits] [PATCH] D67540: [lldb] Remove SetCount/ClearCount from Flags

2019-09-16 Thread Raphael Isemann via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372018: [lldb] Remove SetCount/ClearCount from Flags 
(authored by teemperor, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67540?vs=220051&id=220362#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67540

Files:
  lldb/trunk/include/lldb/Utility/Flags.h
  lldb/trunk/unittests/Utility/FlagsTest.cpp

Index: lldb/trunk/unittests/Utility/FlagsTest.cpp
===
--- lldb/trunk/unittests/Utility/FlagsTest.cpp
+++ lldb/trunk/unittests/Utility/FlagsTest.cpp
@@ -30,19 +30,18 @@
   Flags f;
   f.Reset(0x3);
   EXPECT_EQ(0x3U, f.Get());
-  EXPECT_EQ(2U, f.SetCount());
 }
 
 TEST(Flags, Clear) {
   Flags f;
   f.Reset(0x3);
-  EXPECT_EQ(2U, f.SetCount());
+  EXPECT_EQ(0x3U, f.Get());
 
   f.Clear(0x5);
-  EXPECT_EQ(1U, f.SetCount());
+  EXPECT_EQ(0x2U, f.Get());
 
   f.Clear();
-  EXPECT_EQ(0U, f.SetCount());
+  EXPECT_EQ(0x0U, f.Get());
 }
 
 TEST(Flags, AllSet) {
@@ -162,37 +161,3 @@
   EXPECT_TRUE(f.IsClear(eFlag0));
   EXPECT_TRUE(f.IsClear(eFlag1));
 }
-
-TEST(Flags, ClearCount) {
-  Flags f;
-  EXPECT_EQ(32U, f.ClearCount());
-
-  f.Set(eFlag0);
-  EXPECT_EQ(31U, f.ClearCount());
-
-  f.Set(eFlag0);
-  EXPECT_EQ(31U, f.ClearCount());
-
-  f.Set(eFlag1);
-  EXPECT_EQ(30U, f.ClearCount());
-
-  f.Set(eAllFlags);
-  EXPECT_EQ(29U, f.ClearCount());
-}
-
-TEST(Flags, SetCount) {
-  Flags f;
-  EXPECT_EQ(0U, f.SetCount());
-
-  f.Set(eFlag0);
-  EXPECT_EQ(1U, f.SetCount());
-
-  f.Set(eFlag0);
-  EXPECT_EQ(1U, f.SetCount());
-
-  f.Set(eFlag1);
-  EXPECT_EQ(2U, f.SetCount());
-
-  f.Set(eAllFlags);
-  EXPECT_EQ(3U, f.SetCount());
-}
Index: lldb/trunk/include/lldb/Utility/Flags.h
===
--- lldb/trunk/include/lldb/Utility/Flags.h
+++ lldb/trunk/include/lldb/Utility/Flags.h
@@ -121,32 +121,6 @@
   /// \b true if \a bit is 0, \b false otherwise.
   bool IsClear(ValueType bit) const { return (m_flags & bit) == 0; }
 
-  /// Get the number of zero bits in \a m_flags.
-  ///
-  /// \return
-  /// The number of bits that are set to 0 in the current flags.
-  size_t ClearCount() const {
-size_t count = 0;
-for (ValueType shift = 0; shift < sizeof(ValueType) * 8; ++shift) {
-  if ((m_flags & (1u << shift)) == 0)
-++count;
-}
-return count;
-  }
-
-  /// Get the number of one bits in \a m_flags.
-  ///
-  /// \return
-  /// The number of bits that are set to 1 in the current flags.
-  size_t SetCount() const {
-size_t count = 0;
-for (ValueType mask = m_flags; mask; mask >>= 1) {
-  if (mask & 1u)
-++count;
-}
-return count;
-  }
-
 protected:
   ValueType m_flags; ///< The flags.
 };
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D64853: Fix CommandInterpreter for _regex-break with options

2019-09-16 Thread Raphael Isemann via Phabricator via lldb-commits

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

(setting this to 'request changes' that it leaves the review queue and goes 
back to mib)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64853



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

[Lldb-commits] [lldb] r372028 - [NFC] Move dumping into GDBRemotePacket

2019-09-16 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Mon Sep 16 13:02:57 2019
New Revision: 372028

URL: http://llvm.org/viewvc/llvm-project?rev=372028&view=rev
Log:
[NFC] Move dumping into GDBRemotePacket

This moves the dumping logic from the GDBRemoteCommunicationHistory
class into the GDBRemotePacket so that it can be reused from the
reproducer command object.

Modified:
lldb/trunk/include/lldb/Utility/GDBRemote.h

lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationHistory.cpp
lldb/trunk/source/Utility/GDBRemote.cpp

Modified: lldb/trunk/include/lldb/Utility/GDBRemote.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/GDBRemote.h?rev=372028&r1=372027&r2=372028&view=diff
==
--- lldb/trunk/include/lldb/Utility/GDBRemote.h (original)
+++ lldb/trunk/include/lldb/Utility/GDBRemote.h Mon Sep 16 13:02:57 2019
@@ -70,12 +70,16 @@ struct GDBRemotePacket {
   };
 
   void Serialize(llvm::raw_ostream &strm) const;
+  void Dump(Stream &strm) const;
 
   BinaryData packet;
   Type type;
   uint32_t bytes_transmitted;
   uint32_t packet_idx;
   lldb::tid_t tid;
+
+private:
+  llvm::StringRef GetTypeStr() const;
 };
 
 } // namespace lldb_private

Modified: 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationHistory.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationHistory.cpp?rev=372028&r1=372027&r2=372028&view=diff
==
--- 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationHistory.cpp 
(original)
+++ 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationHistory.cpp 
Mon Sep 16 13:02:57 2019
@@ -72,11 +72,8 @@ void GDBRemoteCommunicationHistory::Dump
 if (entry.type == GDBRemotePacket::ePacketTypeInvalid ||
 entry.packet.data.empty())
   break;
-strm.Printf("history[%u] tid=0x%4.4" PRIx64 " <%4u> %s packet: %s\n",
-entry.packet_idx, entry.tid, entry.bytes_transmitted,
-(entry.type == GDBRemotePacket::ePacketTypeSend) ? "send"
- : "read",
-entry.packet.data.c_str());
+strm.Printf("history[%u] ", entry.packet_idx);
+entry.Dump(strm);
   }
 }
 

Modified: lldb/trunk/source/Utility/GDBRemote.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Utility/GDBRemote.cpp?rev=372028&r1=372027&r2=372028&view=diff
==
--- lldb/trunk/source/Utility/GDBRemote.cpp (original)
+++ lldb/trunk/source/Utility/GDBRemote.cpp Mon Sep 16 13:02:57 2019
@@ -51,6 +51,23 @@ void GDBRemotePacket::Serialize(raw_ostr
   strm.flush();
 }
 
+llvm::StringRef GDBRemotePacket::GetTypeStr() const {
+  switch (type) {
+  case GDBRemotePacket::ePacketTypeSend:
+return "send";
+  case GDBRemotePacket::ePacketTypeRecv:
+return "read";
+  case GDBRemotePacket::ePacketTypeInvalid:
+return "invalid";
+  }
+  llvm_unreachable("All enum cases should be handled");
+}
+
+void GDBRemotePacket::Dump(Stream &strm) const {
+  strm.Printf("tid=0x%4.4" PRIx64 " <%4u> %s packet: %s\n", tid,
+  bytes_transmitted, GetTypeStr().data(), packet.data.c_str());
+}
+
 void yaml::ScalarEnumerationTraits::enumeration(
 IO &io, GDBRemotePacket::Type &value) {
   io.enumCase(value, "Invalid", GDBRemotePacket::ePacketTypeInvalid);


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

[Lldb-commits] [PATCH] D67583: Fix swig python package path

2019-09-16 Thread Haibo Huang via Phabricator via lldb-commits

hhb updated this revision to Diff 220392.
hhb added a comment.

Use CMAKE_HOST_SYSTEM_NAME instead. Since the python script is run on host.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67583

Files:
  lldb/scripts/CMakeLists.txt


Index: lldb/scripts/CMakeLists.txt
===
--- lldb/scripts/CMakeLists.txt
+++ lldb/scripts/CMakeLists.txt
@@ -42,13 +42,15 @@
 )
 
 if(NOT LLDB_BUILD_FRAMEWORK)
-  if(CMAKE_SYSTEM_NAME MATCHES "Windows")
-set(swig_python_subdir site-packages)
+  # The path here should match the result of python function
+  # distutils.sysconfig.get_python_lib().
+  if(CMAKE_HOST_SYSTEM_NAME MATCHES "Windows")
+set(swig_python_subdir Lib/site-packages)
   else()
-set(swig_python_subdir 
python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
+set(swig_python_subdir 
lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
   endif()
 
-  set(SWIG_PYTHON_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${swig_python_subdir})
+  set(SWIG_PYTHON_DIR 
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${swig_python_subdir})
   set(SWIG_INSTALL_DIR lib${LLVM_LIBDIR_SUFFIX})
 
   # Install the LLDB python module


Index: lldb/scripts/CMakeLists.txt
===
--- lldb/scripts/CMakeLists.txt
+++ lldb/scripts/CMakeLists.txt
@@ -42,13 +42,15 @@
 )
 
 if(NOT LLDB_BUILD_FRAMEWORK)
-  if(CMAKE_SYSTEM_NAME MATCHES "Windows")
-set(swig_python_subdir site-packages)
+  # The path here should match the result of python function
+  # distutils.sysconfig.get_python_lib().
+  if(CMAKE_HOST_SYSTEM_NAME MATCHES "Windows")
+set(swig_python_subdir Lib/site-packages)
   else()
-set(swig_python_subdir python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
+set(swig_python_subdir lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
   endif()
 
-  set(SWIG_PYTHON_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${swig_python_subdir})
+  set(SWIG_PYTHON_DIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${swig_python_subdir})
   set(SWIG_INSTALL_DIR lib${LLVM_LIBDIR_SUFFIX})
 
   # Install the LLDB python module
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67636: [Reproducer] Implement dumping packets.

2019-09-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere created this revision.
JDevlieghere added a reviewer: LLDB.
Herald added a project: LLDB.

This adds support for dumping a reproducer's GDB remote packets.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D67636

Files:
  lldb/lit/Reproducer/TestDump.test
  lldb/source/Commands/CommandObjectReproducer.cpp


Index: lldb/source/Commands/CommandObjectReproducer.cpp
===
--- lldb/source/Commands/CommandObjectReproducer.cpp
+++ lldb/source/Commands/CommandObjectReproducer.cpp
@@ -10,6 +10,7 @@
 
 #include "lldb/Host/OptionParser.h"
 #include "lldb/Utility/Reproducer.h"
+#include "lldb/Utility/GDBRemote.h"
 
 #include "lldb/Interpreter/CommandInterpreter.h"
 #include "lldb/Interpreter/CommandReturnObject.h"
@@ -310,9 +311,26 @@
   return true;
 }
 case eReproducerProviderGDB: {
-  // FIXME: Dumping the GDB remote packets means moving the
-  // (de)serialization code out of the GDB-remote plugin.
-  result.AppendMessage("Dumping GDB remote packets isn't implemented 
yet.");
+  FileSpec gdb_file = loader->GetFile();
+  auto error_or_file = MemoryBuffer::getFile(gdb_file.GetPath());
+  if (auto err = error_or_file.getError()) {
+SetError(result, errorCodeToError(err));
+return false;
+  }
+
+  std::vector packets;
+  yaml::Input yin((*error_or_file)->getBuffer());
+  yin >> packets;
+
+  if (auto err = yin.error()) {
+SetError(result, errorCodeToError(err));
+return false;
+  }
+
+  for (GDBRemotePacket& packet : packets) {
+packet.Dump(result.GetOutputStream());
+  }
+
   result.SetStatus(eReturnStatusSuccessFinishResult);
   return true;
 }
Index: lldb/lit/Reproducer/TestDump.test
===
--- lldb/lit/Reproducer/TestDump.test
+++ lldb/lit/Reproducer/TestDump.test
@@ -18,4 +18,8 @@
 # COMMANDS: target create
 # COMMANDS: command source
 
+# RUN: %lldb -b -o 'reproducer dump -p gdb -f %t.repro' | FileCheck %s 
--check-prefix GDB
+# GDB: send packet: $QStartNoAckMode#b0
+# GDB: read packet: $OK#9a
+
 # RUN: %lldb --replay %t.repro | FileCheck %s --check-prefix FILES


Index: lldb/source/Commands/CommandObjectReproducer.cpp
===
--- lldb/source/Commands/CommandObjectReproducer.cpp
+++ lldb/source/Commands/CommandObjectReproducer.cpp
@@ -10,6 +10,7 @@
 
 #include "lldb/Host/OptionParser.h"
 #include "lldb/Utility/Reproducer.h"
+#include "lldb/Utility/GDBRemote.h"
 
 #include "lldb/Interpreter/CommandInterpreter.h"
 #include "lldb/Interpreter/CommandReturnObject.h"
@@ -310,9 +311,26 @@
   return true;
 }
 case eReproducerProviderGDB: {
-  // FIXME: Dumping the GDB remote packets means moving the
-  // (de)serialization code out of the GDB-remote plugin.
-  result.AppendMessage("Dumping GDB remote packets isn't implemented yet.");
+  FileSpec gdb_file = loader->GetFile();
+  auto error_or_file = MemoryBuffer::getFile(gdb_file.GetPath());
+  if (auto err = error_or_file.getError()) {
+SetError(result, errorCodeToError(err));
+return false;
+  }
+
+  std::vector packets;
+  yaml::Input yin((*error_or_file)->getBuffer());
+  yin >> packets;
+
+  if (auto err = yin.error()) {
+SetError(result, errorCodeToError(err));
+return false;
+  }
+
+  for (GDBRemotePacket& packet : packets) {
+packet.Dump(result.GetOutputStream());
+  }
+
   result.SetStatus(eReturnStatusSuccessFinishResult);
   return true;
 }
Index: lldb/lit/Reproducer/TestDump.test
===
--- lldb/lit/Reproducer/TestDump.test
+++ lldb/lit/Reproducer/TestDump.test
@@ -18,4 +18,8 @@
 # COMMANDS: target create
 # COMMANDS: command source
 
+# RUN: %lldb -b -o 'reproducer dump -p gdb -f %t.repro' | FileCheck %s --check-prefix GDB
+# GDB: send packet: $QStartNoAckMode#b0
+# GDB: read packet: $OK#9a
+
 # RUN: %lldb --replay %t.repro | FileCheck %s --check-prefix FILES
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67583: Fix swig python package path

2019-09-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

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

LGTM. Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67583



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

[Lldb-commits] [lldb] r372044 - Fix warning: lambda capture 'temp_file_path' is not used

2019-09-16 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Mon Sep 16 15:55:49 2019
New Revision: 372044

URL: http://llvm.org/viewvc/llvm-project?rev=372044&view=rev
Log:
Fix warning: lambda capture 'temp_file_path' is not used

Modified:
lldb/trunk/tools/lldb-server/lldb-platform.cpp

Modified: lldb/trunk/tools/lldb-server/lldb-platform.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-server/lldb-platform.cpp?rev=372044&r1=372043&r2=372044&view=diff
==
--- lldb/trunk/tools/lldb-server/lldb-platform.cpp (original)
+++ lldb/trunk/tools/lldb-server/lldb-platform.cpp Mon Sep 16 15:55:49 2019
@@ -109,8 +109,7 @@ static Status save_socket_id_to_file(con
   if (auto Err =
   handleErrors(llvm::writeFileAtomically(
temp_file_path, temp_file_spec.GetPath(), 
socket_id),
-   [&status, &temp_file_path,
-&file_spec](const AtomicFileWriteError &E) {
+   [&status, &file_spec](const AtomicFileWriteError &E) {
  std::string ErrorMsgBuffer;
  llvm::raw_string_ostream S(ErrorMsgBuffer);
  E.log(S);


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

[Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

2019-09-16 Thread Guilherme Andrade via Phabricator via lldb-commits

guiandrade added a comment.

In D62931#1607800 , @labath wrote:

> In D62931#1607221 , @guiandrade 
> wrote:
>
> > Oh, sorry about that. I was relying on `ninja check`, which runs okay for 
> > me.
> >
> >   > ninja check
> >[0/1] Running the LLVM regression tests
> >Testing Time: 583.96s
> >  Expected Passes: 32141
> >  Expected Failures  : 147
> >  Unsupported Tests  : 438
> >   
> >
> > How can I invoke those other tests? (in case it's relevant, here's my cmake 
> > command `cmake ../llvm -G Ninja -DLLVM_ENABLE_PROJECTS='lldb;clang;libcxx'`)
>
>
> LLDB tests can be run with the "check-lldb" target. There's also "check-all" 
> which would run *all* tests, but that's usually overkill.
>
> > About not tying `G` and `g` together, maybe could we remove this branch 
> > ?
>
> That would be fine for lldb-server, but I am not sure how would that play 
> with other stubs. As I understand it, the main reason this read-all-at-once 
> logic was introduced was to handle stubs which did not implement `p`/`P` 
> packets, so we may not be able to just start sending `P` unconditionally. 
> @clayborg or @jasonmolenda can probably say more about that...


I'm trying to write a prototype that disassociates the use of 'g' and 'G' 
packets, and I think I found an issue with LLDB's current code and Intel MPX 
registers.

Repro steps:

Using 
https://github.com/llvm/llvm-project/blob/3cabfb344b820586bb7c43212340f64246cde8eb/lldb/lit/Register/Inputs/x86-ymm-read.cpp,
 run:

`g++ -g x86-ymm-read.cpp && lldb a.out -o 'r' -o 'reg read bnd0' -o 'reg read 
ymm12' -o 'reg read bnd0'`

The register `bnd0` will initially be evaluated to `{0x 
0x}` and then to `{0x131211100f0e0d0c 0x1b1a191817161514}`.

I think that's because there's an intersection between the interval 
`[reg_info->byte_offset, reg_info->byte_offset + reg_info->byte_size)` for 
`bnd0` and `ymm12`, which causes data in 
https://github.com/llvm-mirror/lldb/blob/2f97c81e9ed17f6ad759265abfa3f8f49dd7b826/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h#L115
 to get overwritten.

Could someone please confirm that this is an issue?

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62931



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

[Lldb-commits] [lldb] r372046 - [Reproducer] Implement dumping packets.

2019-09-16 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Mon Sep 16 16:31:06 2019
New Revision: 372046

URL: http://llvm.org/viewvc/llvm-project?rev=372046&view=rev
Log:
[Reproducer] Implement dumping packets.

This patch completes the dump functionality by adding support for
dumping a reproducer's GDB remote packets.

Differential revision: https://reviews.llvm.org/D67636

Modified:
lldb/trunk/lit/Reproducer/TestDump.test
lldb/trunk/source/Commands/CommandObjectReproducer.cpp

Modified: lldb/trunk/lit/Reproducer/TestDump.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Reproducer/TestDump.test?rev=372046&r1=372045&r2=372046&view=diff
==
--- lldb/trunk/lit/Reproducer/TestDump.test (original)
+++ lldb/trunk/lit/Reproducer/TestDump.test Mon Sep 16 16:31:06 2019
@@ -18,4 +18,8 @@
 # COMMANDS: target create
 # COMMANDS: command source
 
+# RUN: %lldb -b -o 'reproducer dump -p gdb -f %t.repro' | FileCheck %s 
--check-prefix GDB
+# GDB: send packet: $QStartNoAckMode#b0
+# GDB: read packet: $OK#9a
+
 # RUN: %lldb --replay %t.repro | FileCheck %s --check-prefix FILES

Modified: lldb/trunk/source/Commands/CommandObjectReproducer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectReproducer.cpp?rev=372046&r1=372045&r2=372046&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectReproducer.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectReproducer.cpp Mon Sep 16 16:31:06 
2019
@@ -10,6 +10,7 @@
 
 #include "lldb/Host/OptionParser.h"
 #include "lldb/Utility/Reproducer.h"
+#include "lldb/Utility/GDBRemote.h"
 
 #include "lldb/Interpreter/CommandInterpreter.h"
 #include "lldb/Interpreter/CommandReturnObject.h"
@@ -310,9 +311,26 @@ protected:
   return true;
 }
 case eReproducerProviderGDB: {
-  // FIXME: Dumping the GDB remote packets means moving the
-  // (de)serialization code out of the GDB-remote plugin.
-  result.AppendMessage("Dumping GDB remote packets isn't implemented 
yet.");
+  FileSpec gdb_file = loader->GetFile();
+  auto error_or_file = MemoryBuffer::getFile(gdb_file.GetPath());
+  if (auto err = error_or_file.getError()) {
+SetError(result, errorCodeToError(err));
+return false;
+  }
+
+  std::vector packets;
+  yaml::Input yin((*error_or_file)->getBuffer());
+  yin >> packets;
+
+  if (auto err = yin.error()) {
+SetError(result, errorCodeToError(err));
+return false;
+  }
+
+  for (GDBRemotePacket& packet : packets) {
+packet.Dump(result.GetOutputStream());
+  }
+
   result.SetStatus(eReturnStatusSuccessFinishResult);
   return true;
 }


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

[Lldb-commits] [PATCH] D67636: [Reproducer] Implement dumping packets.

2019-09-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372046: [Reproducer] Implement dumping packets. (authored by 
JDevlieghere, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67636?vs=220395&id=220403#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67636

Files:
  lldb/trunk/lit/Reproducer/TestDump.test
  lldb/trunk/source/Commands/CommandObjectReproducer.cpp


Index: lldb/trunk/source/Commands/CommandObjectReproducer.cpp
===
--- lldb/trunk/source/Commands/CommandObjectReproducer.cpp
+++ lldb/trunk/source/Commands/CommandObjectReproducer.cpp
@@ -10,6 +10,7 @@
 
 #include "lldb/Host/OptionParser.h"
 #include "lldb/Utility/Reproducer.h"
+#include "lldb/Utility/GDBRemote.h"
 
 #include "lldb/Interpreter/CommandInterpreter.h"
 #include "lldb/Interpreter/CommandReturnObject.h"
@@ -310,9 +311,26 @@
   return true;
 }
 case eReproducerProviderGDB: {
-  // FIXME: Dumping the GDB remote packets means moving the
-  // (de)serialization code out of the GDB-remote plugin.
-  result.AppendMessage("Dumping GDB remote packets isn't implemented 
yet.");
+  FileSpec gdb_file = loader->GetFile();
+  auto error_or_file = MemoryBuffer::getFile(gdb_file.GetPath());
+  if (auto err = error_or_file.getError()) {
+SetError(result, errorCodeToError(err));
+return false;
+  }
+
+  std::vector packets;
+  yaml::Input yin((*error_or_file)->getBuffer());
+  yin >> packets;
+
+  if (auto err = yin.error()) {
+SetError(result, errorCodeToError(err));
+return false;
+  }
+
+  for (GDBRemotePacket& packet : packets) {
+packet.Dump(result.GetOutputStream());
+  }
+
   result.SetStatus(eReturnStatusSuccessFinishResult);
   return true;
 }
Index: lldb/trunk/lit/Reproducer/TestDump.test
===
--- lldb/trunk/lit/Reproducer/TestDump.test
+++ lldb/trunk/lit/Reproducer/TestDump.test
@@ -18,4 +18,8 @@
 # COMMANDS: target create
 # COMMANDS: command source
 
+# RUN: %lldb -b -o 'reproducer dump -p gdb -f %t.repro' | FileCheck %s 
--check-prefix GDB
+# GDB: send packet: $QStartNoAckMode#b0
+# GDB: read packet: $OK#9a
+
 # RUN: %lldb --replay %t.repro | FileCheck %s --check-prefix FILES


Index: lldb/trunk/source/Commands/CommandObjectReproducer.cpp
===
--- lldb/trunk/source/Commands/CommandObjectReproducer.cpp
+++ lldb/trunk/source/Commands/CommandObjectReproducer.cpp
@@ -10,6 +10,7 @@
 
 #include "lldb/Host/OptionParser.h"
 #include "lldb/Utility/Reproducer.h"
+#include "lldb/Utility/GDBRemote.h"
 
 #include "lldb/Interpreter/CommandInterpreter.h"
 #include "lldb/Interpreter/CommandReturnObject.h"
@@ -310,9 +311,26 @@
   return true;
 }
 case eReproducerProviderGDB: {
-  // FIXME: Dumping the GDB remote packets means moving the
-  // (de)serialization code out of the GDB-remote plugin.
-  result.AppendMessage("Dumping GDB remote packets isn't implemented yet.");
+  FileSpec gdb_file = loader->GetFile();
+  auto error_or_file = MemoryBuffer::getFile(gdb_file.GetPath());
+  if (auto err = error_or_file.getError()) {
+SetError(result, errorCodeToError(err));
+return false;
+  }
+
+  std::vector packets;
+  yaml::Input yin((*error_or_file)->getBuffer());
+  yin >> packets;
+
+  if (auto err = yin.error()) {
+SetError(result, errorCodeToError(err));
+return false;
+  }
+
+  for (GDBRemotePacket& packet : packets) {
+packet.Dump(result.GetOutputStream());
+  }
+
   result.SetStatus(eReturnStatusSuccessFinishResult);
   return true;
 }
Index: lldb/trunk/lit/Reproducer/TestDump.test
===
--- lldb/trunk/lit/Reproducer/TestDump.test
+++ lldb/trunk/lit/Reproducer/TestDump.test
@@ -18,4 +18,8 @@
 # COMMANDS: target create
 # COMMANDS: command source
 
+# RUN: %lldb -b -o 'reproducer dump -p gdb -f %t.repro' | FileCheck %s --check-prefix GDB
+# GDB: send packet: $QStartNoAckMode#b0
+# GDB: read packet: $OK#9a
+
 # RUN: %lldb --replay %t.repro | FileCheck %s --check-prefix FILES
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67583: Fix swig python package path

2019-09-16 Thread Haibo Huang via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372047: Fix swig python package path (authored by hhb, 
committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67583?vs=220392&id=220404#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67583

Files:
  lldb/trunk/scripts/CMakeLists.txt


Index: lldb/trunk/scripts/CMakeLists.txt
===
--- lldb/trunk/scripts/CMakeLists.txt
+++ lldb/trunk/scripts/CMakeLists.txt
@@ -42,13 +42,15 @@
 )
 
 if(NOT LLDB_BUILD_FRAMEWORK)
-  if(CMAKE_SYSTEM_NAME MATCHES "Windows")
-set(swig_python_subdir site-packages)
+  # The path here should match the result of python function
+  # distutils.sysconfig.get_python_lib().
+  if(CMAKE_HOST_SYSTEM_NAME MATCHES "Windows")
+set(swig_python_subdir Lib/site-packages)
   else()
-set(swig_python_subdir 
python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
+set(swig_python_subdir 
lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
   endif()
 
-  set(SWIG_PYTHON_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${swig_python_subdir})
+  set(SWIG_PYTHON_DIR 
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${swig_python_subdir})
   set(SWIG_INSTALL_DIR lib${LLVM_LIBDIR_SUFFIX})
 
   # Install the LLDB python module


Index: lldb/trunk/scripts/CMakeLists.txt
===
--- lldb/trunk/scripts/CMakeLists.txt
+++ lldb/trunk/scripts/CMakeLists.txt
@@ -42,13 +42,15 @@
 )
 
 if(NOT LLDB_BUILD_FRAMEWORK)
-  if(CMAKE_SYSTEM_NAME MATCHES "Windows")
-set(swig_python_subdir site-packages)
+  # The path here should match the result of python function
+  # distutils.sysconfig.get_python_lib().
+  if(CMAKE_HOST_SYSTEM_NAME MATCHES "Windows")
+set(swig_python_subdir Lib/site-packages)
   else()
-set(swig_python_subdir python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
+set(swig_python_subdir lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
   endif()
 
-  set(SWIG_PYTHON_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${swig_python_subdir})
+  set(SWIG_PYTHON_DIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${swig_python_subdir})
   set(SWIG_INSTALL_DIR lib${LLVM_LIBDIR_SUFFIX})
 
   # Install the LLDB python module
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67641: Cache PYTHON_EXECUTABLE for windows

2019-09-16 Thread Haibo Huang via Phabricator via lldb-commits

hhb created this revision.
Herald added subscribers: lldb-commits, mgorny.
Herald added a project: LLDB.
hhb added a reviewer: JDevlieghere.

This way it can be overwritten when cross compiling.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67641

Files:
  lldb/cmake/modules/LLDBConfig.cmake


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -250,7 +250,7 @@
   endif()
 
   # Set the same variables as FindPythonInterp and FindPythonLibs.
-  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  PARENT_SCOPE)
+  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  CACHE PATH 
"Path to python executable.")
   set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" PARENT_SCOPE)
   set(PYTHON_DLL"${PYTHON_DLL}" PARENT_SCOPE)
   set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" PARENT_SCOPE)


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -250,7 +250,7 @@
   endif()
 
   # Set the same variables as FindPythonInterp and FindPythonLibs.
-  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  PARENT_SCOPE)
+  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  CACHE PATH "Path to python executable.")
   set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" PARENT_SCOPE)
   set(PYTHON_DLL"${PYTHON_DLL}" PARENT_SCOPE)
   set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" PARENT_SCOPE)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r372052 - [test] Fail gracefully if the regex doesn't match

2019-09-16 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Mon Sep 16 16:49:42 2019
New Revision: 372052

URL: http://llvm.org/viewvc/llvm-project?rev=372052&view=rev
Log:
[test] Fail gracefully if the regex doesn't match

This test is failing on the Fedora bot (staging). Rather than failing
with an IndexError, we should trigger an assert and dump the log when
the regex doesn't match.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/api/log/TestAPILog.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/api/log/TestAPILog.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/api/log/TestAPILog.py?rev=372052&r1=372051&r2=372052&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/api/log/TestAPILog.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/api/log/TestAPILog.py Mon Sep 16 
16:49:42 2019
@@ -34,15 +34,20 @@ class APILogTestCase(TestBase):
 with open(logfile, 'r') as f:
 log = f.read()
 
-# Find the debugger addr.
+# Find the SBDebugger's address.
 debugger_addr = re.findall(
 r"lldb::SBDebugger::GetScriptingLanguage\(const char \*\) 
\(0x([0-9a-fA-F]+),",
-log)[0]
+log)
 
-get_scripting_language = 'lldb::SBDebugger::GetScriptingLanguage(const 
char *) (0x{}, "")'.format(
-debugger_addr)
-create_target = 'lldb::SBDebugger::CreateTarget(const char *) (0x{}, 
"")'.format(
-debugger_addr)
+# Make sure we've found a match.
+self.assertTrue(debugger_addr, log)
 
+# Make sure the GetScriptingLanguage matches.
+get_scripting_language = 'lldb::SBDebugger::GetScriptingLanguage(const 
char *) (0x{}, "")'.format(
+debugger_addr[0])
 self.assertTrue(get_scripting_language in log, log)
+
+# Make sure the address matches.
+create_target = 'lldb::SBDebugger::CreateTarget(const char *) (0x{}, 
"")'.format(
+debugger_addr[0])
 self.assertTrue(create_target in log, log)


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

[Lldb-commits] [PATCH] D67641: Cache PYTHON_EXECUTABLE for windows

2019-09-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

Can we match what `FindPythonInterp ` and `FindPythonLibs` does?

  mark_as_advanced(
PYTHON_EXECUTABLE
PYTHON_DEBUG_LIBRARY
PYTHON_LIBRARY
PYTHON_INCLUDE_DIR
  )


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67641



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

[Lldb-commits] [PATCH] D67641: Cache PYTHON_EXECUTABLE for windows

2019-09-16 Thread Haibo Huang via Phabricator via lldb-commits

hhb added a comment.

In D67641#1671881 , @JDevlieghere 
wrote:

> Can we match what `FindPythonInterp ` and `FindPythonLibs` does?
>
>   mark_as_advanced(
> PYTHON_EXECUTABLE
> PYTHON_DEBUG_LIBRARY
> PYTHON_LIBRARY
> PYTHON_INCLUDE_DIR
>   )
>


Added for PYTHON_EXECUTABLE.

PYTHON_HOME is required, and other variables are derived from PYTHON_HOME. I 
don't think anyone will be interested in setting them separately...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67641



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

[Lldb-commits] [PATCH] D67641: Cache PYTHON_EXECUTABLE for windows

2019-09-16 Thread Haibo Huang via Phabricator via lldb-commits

hhb updated this revision to Diff 220410.
hhb added a comment.

Add mark_as_advanced.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67641

Files:
  lldb/cmake/modules/LLDBConfig.cmake


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -250,7 +250,7 @@
   endif()
 
   # Set the same variables as FindPythonInterp and FindPythonLibs.
-  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  PARENT_SCOPE)
+  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  CACHE PATH 
"Path to python executable.")
   set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" PARENT_SCOPE)
   set(PYTHON_DLL"${PYTHON_DLL}" PARENT_SCOPE)
   set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" PARENT_SCOPE)
@@ -260,6 +260,8 @@
   set(PYTHON_VERSION_MINOR  "${PYTHON_VERSION_MINOR}"   PARENT_SCOPE)
   set(PYTHON_VERSION_PATCH  "${PYTHON_VERSION_PATCH}"   PARENT_SCOPE)
 
+  mark_as_advanced(PYTHON_EXECUTABLE)
+
   message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXECUTABLE} 
(${PYTHON_VERSION_STRING})")
   message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIBRARY} 
(${PYTHONLIBS_VERSION_STRING})")
   message(STATUS "LLDB Found PythonDLL: ${PYTHON_DLL}")


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -250,7 +250,7 @@
   endif()
 
   # Set the same variables as FindPythonInterp and FindPythonLibs.
-  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  PARENT_SCOPE)
+  set(PYTHON_EXECUTABLE "${PYTHON_EXECUTABLE}"  CACHE PATH "Path to python executable.")
   set(PYTHON_LIBRARY"${PYTHON_LIBRARY}" PARENT_SCOPE)
   set(PYTHON_DLL"${PYTHON_DLL}" PARENT_SCOPE)
   set(PYTHON_INCLUDE_DIR"${PYTHON_INCLUDE_DIR}" PARENT_SCOPE)
@@ -260,6 +260,8 @@
   set(PYTHON_VERSION_MINOR  "${PYTHON_VERSION_MINOR}"   PARENT_SCOPE)
   set(PYTHON_VERSION_PATCH  "${PYTHON_VERSION_PATCH}"   PARENT_SCOPE)
 
+  mark_as_advanced(PYTHON_EXECUTABLE)
+
   message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXECUTABLE} (${PYTHON_VERSION_STRING})")
   message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIBRARY} (${PYTHONLIBS_VERSION_STRING})")
   message(STATUS "LLDB Found PythonDLL: ${PYTHON_DLL}")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67641: Cache PYTHON_EXECUTABLE for windows

2019-09-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

In D67641#1671917 , @hhb wrote:

> In D67641#1671881 , @JDevlieghere 
> wrote:
>
> > Can we match what `FindPythonInterp ` and `FindPythonLibs` does?
> >
> >   mark_as_advanced(
> > PYTHON_EXECUTABLE
> > PYTHON_DEBUG_LIBRARY
> > PYTHON_LIBRARY
> > PYTHON_INCLUDE_DIR
> >   )
> >
>
>
> Added for PYTHON_EXECUTABLE.
>
> PYTHON_HOME is required, and other variables are derived from PYTHON_HOME. I 
> don't think anyone will be interested in setting them separately...


With `mark_as_advanced` you don't have to modify the code above. Even if 
they're not needed, I'd still prefer to include the other variables as well, 
just to maintain consistency with was CMake does.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67641



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

[Lldb-commits] [lldb] r372057 - Revert "[lldb][NFC] Make ApplyObjcCastHack less scary"

2019-09-16 Thread Jim Ingham via lldb-commits

Author: jingham
Date: Mon Sep 16 17:44:48 2019
New Revision: 372057

URL: http://llvm.org/viewvc/llvm-project?rev=372057&view=rev
Log:
Revert "[lldb][NFC] Make ApplyObjcCastHack less scary"

This reverts commit 21641a2f6dbac22653befd03496e0850537882ff.

It was causing the following test failures:

lldb-Suite.lang/objc/objc-class-method.TestObjCClassMethod.py
lldb-Suite.lang/objc/foundation.TestObjCMethodsString.py
lldb-Suite.lang/objc/foundation.TestConstStrings.py
lldb-Suite.lang/objc/radar-9691614.TestObjCMethodReturningBOOL.py
lldb-Suite.lang/objc/foundation.TestObjCMethodsNSArray.py

Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp

Modified: 
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp?rev=372057&r1=372056&r2=372057&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp 
(original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp 
Mon Sep 16 17:44:48 2019
@@ -313,13 +313,17 @@ void ClangUserExpression::ScanContext(Ex
 // count is not available, [myArray count] returns id, which can't be directly
 // cast to int without causing a clang error.
 static void ApplyObjcCastHack(std::string &expr) {
-  std::string from = "(int)[";
-  std::string to = "(int)(long long)[";
+#define OBJC_CAST_HACK_FROM "(int)["
+#define OBJC_CAST_HACK_TO "(int)(long long)["
 
-  size_t offset;
+  size_t from_offset;
 
-  while ((offset = expr.find(from)) != expr.npos)
-expr.replace(offset, to.size(), to);
+  while ((from_offset = expr.find(OBJC_CAST_HACK_FROM)) != expr.npos)
+expr.replace(from_offset, sizeof(OBJC_CAST_HACK_FROM) - 1,
+ OBJC_CAST_HACK_TO);
+
+#undef OBJC_CAST_HACK_TO
+#undef OBJC_CAST_HACK_FROM
 }
 
 bool ClangUserExpression::SetupPersistentState(DiagnosticManager 
&diagnostic_manager,


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

[Lldb-commits] [PATCH] D67644: [ScriptInterpreter] Initialize globals when loading a scripting module.

2019-09-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere created this revision.
JDevlieghere added reviewers: davide, jingham.
JDevlieghere added a project: LLDB.
Herald added a subscriber: teemperor.

The `LoadScriptingModule` used by `command script import` wasn't initializing 
the LLDB global variables (things like `lldb.frame` and `lldb.debugger`). They 
would get initialized however when running the interactive script interpreter 
or running a single script line (e.g. `script print(lldb.frame)`). This patch 
fixes that by properly initializing the globals when loading a Python module.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D67644

Files:
  lldb/lit/Commands/Inputs/frame.py
  lldb/lit/Commands/command-script-import.test
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp


Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -2699,12 +2699,12 @@
 StreamString command_stream;
 
 // Before executing Python code, lock the GIL.
-Locker py_lock(this,
-   Locker::AcquireLock |
-   (init_session ? Locker::InitSession : 0) |
-   Locker::NoSTDIN,
-   Locker::FreeAcquiredLock |
-   (init_session ? Locker::TearDownSession : 0));
+Locker py_lock(
+this,
+Locker::AcquireLock | (init_session ? Locker::InitSession : 0) |
+(init_session ? Locker::InitGlobals : 0) | Locker::NoSTDIN,
+Locker::FreeAcquiredLock |
+(init_session ? Locker::TearDownSession : 0));
 namespace fs = llvm::sys::fs;
 fs::file_status st;
 std::error_code ec = status(target_file.GetPath(), st);
Index: lldb/lit/Commands/command-script-import.test
===
--- /dev/null
+++ lldb/lit/Commands/command-script-import.test
@@ -0,0 +1,8 @@
+# RUN: echo 'b main' > %t.in
+# RUN: echo 'run' >> %t.in
+# RUN: echo 'command script import %S/Inputs/frame.py' >> %t.in
+
+# RUN: %clang -g -O0 %S/../Settings/Inputs/main.c -o %t.out
+# RUN: %lldb -b -s %t.in %t.out | FileCheck %s
+
+# CHECK: frame #0
Index: lldb/lit/Commands/Inputs/frame.py
===
--- /dev/null
+++ lldb/lit/Commands/Inputs/frame.py
@@ -0,0 +1,2 @@
+import lldb
+print(lldb.frame)
\ No newline at end of file


Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -2699,12 +2699,12 @@
 StreamString command_stream;
 
 // Before executing Python code, lock the GIL.
-Locker py_lock(this,
-   Locker::AcquireLock |
-   (init_session ? Locker::InitSession : 0) |
-   Locker::NoSTDIN,
-   Locker::FreeAcquiredLock |
-   (init_session ? Locker::TearDownSession : 0));
+Locker py_lock(
+this,
+Locker::AcquireLock | (init_session ? Locker::InitSession : 0) |
+(init_session ? Locker::InitGlobals : 0) | Locker::NoSTDIN,
+Locker::FreeAcquiredLock |
+(init_session ? Locker::TearDownSession : 0));
 namespace fs = llvm::sys::fs;
 fs::file_status st;
 std::error_code ec = status(target_file.GetPath(), st);
Index: lldb/lit/Commands/command-script-import.test
===
--- /dev/null
+++ lldb/lit/Commands/command-script-import.test
@@ -0,0 +1,8 @@
+# RUN: echo 'b main' > %t.in
+# RUN: echo 'run' >> %t.in
+# RUN: echo 'command script import %S/Inputs/frame.py' >> %t.in
+
+# RUN: %clang -g -O0 %S/../Settings/Inputs/main.c -o %t.out
+# RUN: %lldb -b -s %t.in %t.out | FileCheck %s
+
+# CHECK: frame #0
Index: lldb/lit/Commands/Inputs/frame.py
===
--- /dev/null
+++ lldb/lit/Commands/Inputs/frame.py
@@ -0,0 +1,2 @@
+import lldb
+print(lldb.frame)
\ No newline at end of file
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67644: [ScriptInterpreter] Initialize globals when loading a scripting module.

2019-09-16 Thread Davide Italiano via Phabricator via lldb-commits

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

LGTM


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D67644



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

[Lldb-commits] [PATCH] D67641: Cache PYTHON_EXECUTABLE for windows

2019-09-16 Thread Haibo Huang via Phabricator via lldb-commits

hhb updated this revision to Diff 220424.
hhb added a comment.

Fix comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67641

Files:
  lldb/cmake/modules/LLDBConfig.cmake


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -260,6 +260,13 @@
   set(PYTHON_VERSION_MINOR  "${PYTHON_VERSION_MINOR}"   PARENT_SCOPE)
   set(PYTHON_VERSION_PATCH  "${PYTHON_VERSION_PATCH}"   PARENT_SCOPE)
 
+  mark_as_advanced(
+PYTHON_EXECUTABLE
+PYTHON_LIBRARY
+PYTHON_DLL
+PYTHON_INCLUDE_DIR
+  )
+
   message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXECUTABLE} 
(${PYTHON_VERSION_STRING})")
   message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIBRARY} 
(${PYTHONLIBS_VERSION_STRING})")
   message(STATUS "LLDB Found PythonDLL: ${PYTHON_DLL}")


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -260,6 +260,13 @@
   set(PYTHON_VERSION_MINOR  "${PYTHON_VERSION_MINOR}"   PARENT_SCOPE)
   set(PYTHON_VERSION_PATCH  "${PYTHON_VERSION_PATCH}"   PARENT_SCOPE)
 
+  mark_as_advanced(
+PYTHON_EXECUTABLE
+PYTHON_LIBRARY
+PYTHON_DLL
+PYTHON_INCLUDE_DIR
+  )
+
   message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXECUTABLE} (${PYTHON_VERSION_STRING})")
   message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIBRARY} (${PYTHONLIBS_VERSION_STRING})")
   message(STATUS "LLDB Found PythonDLL: ${PYTHON_DLL}")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67644: [ScriptInterpreter] Initialize globals when loading a scripting module.

2019-09-16 Thread Fangrui Song via Phabricator via lldb-commits

MaskRay added inline comments.



Comment at: lldb/lit/Commands/Inputs/frame.py:3
+print(lldb.frame)
\ No newline at end of file


No newline at end of file


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D67644



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

[Lldb-commits] [lldb] r372060 - [ScriptInterpreter] Initialize globals when loading a scripting module.

2019-09-16 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Mon Sep 16 20:55:58 2019
New Revision: 372060

URL: http://llvm.org/viewvc/llvm-project?rev=372060&view=rev
Log:
[ScriptInterpreter] Initialize globals when loading a scripting module.

The LoadScriptingModule used by command script import wasn't
initializing the LLDB global variables (things like `lldb.frame` and
`lldb.debugger`). They would get initialized however when running the
interactive script interpreter or running a single script line (e.g.
`script print(lldb.frame)`). This patch fixes that by properly
initializing the globals when loading a Python module.

Differential revision: https://reviews.llvm.org/D67644

Added:
lldb/trunk/lit/Commands/Inputs/
lldb/trunk/lit/Commands/Inputs/frame.py
lldb/trunk/lit/Commands/command-script-import.test
Modified:

lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Added: lldb/trunk/lit/Commands/Inputs/frame.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Commands/Inputs/frame.py?rev=372060&view=auto
==
--- lldb/trunk/lit/Commands/Inputs/frame.py (added)
+++ lldb/trunk/lit/Commands/Inputs/frame.py Mon Sep 16 20:55:58 2019
@@ -0,0 +1,2 @@
+import lldb
+print(lldb.frame)

Added: lldb/trunk/lit/Commands/command-script-import.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Commands/command-script-import.test?rev=372060&view=auto
==
--- lldb/trunk/lit/Commands/command-script-import.test (added)
+++ lldb/trunk/lit/Commands/command-script-import.test Mon Sep 16 20:55:58 2019
@@ -0,0 +1,8 @@
+# RUN: echo 'b main' > %t.in
+# RUN: echo 'run' >> %t.in
+# RUN: echo 'command script import %S/Inputs/frame.py' >> %t.in
+
+# RUN: %clang -g -O0 %S/../Settings/Inputs/main.c -o %t.out
+# RUN: %lldb -b -s %t.in %t.out | FileCheck %s
+
+# CHECK: frame #0

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp?rev=372060&r1=372059&r2=372060&view=diff
==
--- 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
(original)
+++ 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
Mon Sep 16 20:55:58 2019
@@ -2699,12 +2699,12 @@ bool ScriptInterpreterPythonImpl::LoadSc
 StreamString command_stream;
 
 // Before executing Python code, lock the GIL.
-Locker py_lock(this,
-   Locker::AcquireLock |
-   (init_session ? Locker::InitSession : 0) |
-   Locker::NoSTDIN,
-   Locker::FreeAcquiredLock |
-   (init_session ? Locker::TearDownSession : 0));
+Locker py_lock(
+this,
+Locker::AcquireLock | (init_session ? Locker::InitSession : 0) |
+(init_session ? Locker::InitGlobals : 0) | Locker::NoSTDIN,
+Locker::FreeAcquiredLock |
+(init_session ? Locker::TearDownSession : 0));
 namespace fs = llvm::sys::fs;
 fs::file_status st;
 std::error_code ec = status(target_file.GetPath(), st);


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

[Lldb-commits] [PATCH] D67644: [ScriptInterpreter] Initialize globals when loading a scripting module.

2019-09-16 Thread Jonas Devlieghere via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372060: [ScriptInterpreter] Initialize globals when loading 
a scripting module. (authored by JDevlieghere, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67644?vs=220415&id=220430#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67644

Files:
  lldb/trunk/lit/Commands/Inputs/frame.py
  lldb/trunk/lit/Commands/command-script-import.test
  lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp


Index: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -2699,12 +2699,12 @@
 StreamString command_stream;
 
 // Before executing Python code, lock the GIL.
-Locker py_lock(this,
-   Locker::AcquireLock |
-   (init_session ? Locker::InitSession : 0) |
-   Locker::NoSTDIN,
-   Locker::FreeAcquiredLock |
-   (init_session ? Locker::TearDownSession : 0));
+Locker py_lock(
+this,
+Locker::AcquireLock | (init_session ? Locker::InitSession : 0) |
+(init_session ? Locker::InitGlobals : 0) | Locker::NoSTDIN,
+Locker::FreeAcquiredLock |
+(init_session ? Locker::TearDownSession : 0));
 namespace fs = llvm::sys::fs;
 fs::file_status st;
 std::error_code ec = status(target_file.GetPath(), st);
Index: lldb/trunk/lit/Commands/command-script-import.test
===
--- lldb/trunk/lit/Commands/command-script-import.test
+++ lldb/trunk/lit/Commands/command-script-import.test
@@ -0,0 +1,8 @@
+# RUN: echo 'b main' > %t.in
+# RUN: echo 'run' >> %t.in
+# RUN: echo 'command script import %S/Inputs/frame.py' >> %t.in
+
+# RUN: %clang -g -O0 %S/../Settings/Inputs/main.c -o %t.out
+# RUN: %lldb -b -s %t.in %t.out | FileCheck %s
+
+# CHECK: frame #0
Index: lldb/trunk/lit/Commands/Inputs/frame.py
===
--- lldb/trunk/lit/Commands/Inputs/frame.py
+++ lldb/trunk/lit/Commands/Inputs/frame.py
@@ -0,0 +1,2 @@
+import lldb
+print(lldb.frame)


Index: lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -2699,12 +2699,12 @@
 StreamString command_stream;
 
 // Before executing Python code, lock the GIL.
-Locker py_lock(this,
-   Locker::AcquireLock |
-   (init_session ? Locker::InitSession : 0) |
-   Locker::NoSTDIN,
-   Locker::FreeAcquiredLock |
-   (init_session ? Locker::TearDownSession : 0));
+Locker py_lock(
+this,
+Locker::AcquireLock | (init_session ? Locker::InitSession : 0) |
+(init_session ? Locker::InitGlobals : 0) | Locker::NoSTDIN,
+Locker::FreeAcquiredLock |
+(init_session ? Locker::TearDownSession : 0));
 namespace fs = llvm::sys::fs;
 fs::file_status st;
 std::error_code ec = status(target_file.GetPath(), st);
Index: lldb/trunk/lit/Commands/command-script-import.test
===
--- lldb/trunk/lit/Commands/command-script-import.test
+++ lldb/trunk/lit/Commands/command-script-import.test
@@ -0,0 +1,8 @@
+# RUN: echo 'b main' > %t.in
+# RUN: echo 'run' >> %t.in
+# RUN: echo 'command script import %S/Inputs/frame.py' >> %t.in
+
+# RUN: %clang -g -O0 %S/../Settings/Inputs/main.c -o %t.out
+# RUN: %lldb -b -s %t.in %t.out | FileCheck %s
+
+# CHECK: frame #0
Index: lldb/trunk/lit/Commands/Inputs/frame.py
===
--- lldb/trunk/lit/Commands/Inputs/frame.py
+++ lldb/trunk/lit/Commands/Inputs/frame.py
@@ -0,0 +1,2 @@
+import lldb
+print(lldb.frame)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r372064 - [test] Disable reproducer dump test on Windows

2019-09-16 Thread Jonas Devlieghere via lldb-commits

Author: jdevlieghere
Date: Mon Sep 16 20:58:32 2019
New Revision: 372064

URL: http://llvm.org/viewvc/llvm-project?rev=372064&view=rev
Log:
[test] Disable reproducer dump test on Windows

Modified:
lldb/trunk/lit/Reproducer/TestDump.test

Modified: lldb/trunk/lit/Reproducer/TestDump.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Reproducer/TestDump.test?rev=372064&r1=372063&r2=372064&view=diff
==
--- lldb/trunk/lit/Reproducer/TestDump.test (original)
+++ lldb/trunk/lit/Reproducer/TestDump.test Mon Sep 16 20:58:32 2019
@@ -1,3 +1,4 @@
+# UNSUPPORTED: system-windows
 # This tests the reproducer dump functionality.
 
 # Generate a reproducer.


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

45 matches

Mail list logo