Re: [lldb-dev] Python3 compatibility for the API

2016-08-30 Thread Luke Drummond via lldb-dev 

Hi Zachary, Peter

On 30/08/16 00:14, Zachary Turner via lldb-dev wrote:

Right, the existing version that is built and what you are using links
directly against a 2.7 libpython at compile time.  So you would probably
need to build LLDB from source and tweak the build system to make it
possible to link against your 3.x version of python.  There's some build
instructions on the website .  I know
there's a few linux developers around here, so it's possible someone
else would be interested in making this work as well, but I don't know
that it's on anyone's immediate timeline.


We build lldb against python3 regularly, because - as Zachary said - 
this is the only way to get scripting support on windows. To link 
against python3 on Linux you *should* just need the correct headers 
installed, and invoke CMake with the correct python path. For Ubuntu:


```
sudo apt install python3-dev
cmake "$PATH_TO_LLVM_SRC" -DPYTHON_EXECUTABLE:FILEPATH=$(which python3)
```

*should* give you everything you need. However, you may see that cmake 
picks up the python3 interpreter correctly, but tries to link against 
the python2.7 library.


-- Found PythonInterp: /usr/bin/python3 (found version "3.5.2")
[...]
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found 
version "2.7.12")


This appears to be due to a problem in LLVM's CMakeLists.txt specifying 
support for 2.7 only. I have a patch to fix the issue awaiting review 
[here](https://reviews.llvm.org/D20825) which should fix the issue on 
Linux when multiple pythons are installed. It may be worth applying this 
patch locally and see how you get on.


Hope that helps

Best

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

Re: [lldb-dev] DWARFASTParserClang and DW_TAG_typedef for anonymous structs

2016-03-11 Thread Luke Drummond via lldb-dev 
g a non-null TypeSP after 
fallthrough in DWARFASTParserClang::ParseTypeFromDWARF, but it seems that with 
an empty name it doesn't allow clang to resolve the type, failing to locate 
mangled function as the typename is wrong (_Z6myfuncP3$_0).

A colleague took a look at this today, and as a quick sanity test, threw 
together this hack:

--- a/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -553,6 +553,19 @@ DWARFASTParserClang::ParseTypeFromDWARF (const 
SymbolContext& sc,
}
}

+{
+uint32_t list_size = type_list->GetSize();
+for (uint32_t i = 0; i < list_size; ++i)
+{
+TypeSP t = type_list->GetTypeAtIndex(i);
+if (t->IsTypedef())
+{
+   type_name_const_str = t->GetName();
+   type_name_cstr = t->GetName().AsCString();
+            }
+    }
+}


It seems to fix our problem here and expression evaluation works again for the 
presented case, but unfortunately, a few other tests break, which is a little 
frustrating. If you have time to take another look at why this might be the 
case, it'd be very much appreciated.

I've attached an example Mac binary of this issue in action built with an older 
Apple clang++, (it's simply the test above) but the result is the same for me 
on Linux with upstream clang++ and g++5.3, so I don't think the age of the 
compiler is a problem here.

Thanks again

Luke


Greg Clayton



On Mar 9, 2016, at 3:54 PM, luke Drummond via lldb-dev 
<lldb-dev@lists.llvm.org> wrote:

Hi All

I'm hoping that someone might be able to give me some direction
regarding `Type` resolution from DWARF informationfor functions taking
anonymous structs hidden behind a typedef

e.g.

```
typedef struct {
   int i;
   float f;
} my_untagged_struct;

void __attribute__((noinline)) myfunc(my_untagged_struct *s)
{
   s->i = 0;
   s->f = 3.14f;
}

int main()
{
   my_untagged_struct s;
   myfunc();
   return 0;
}

```

I [recently reported a
bug](https://llvm.org/bugs/show_bug.cgi?id=26790) relating to the
clang expression evaluator no longer being able to resolve calls to
functions with arguments to typedefed anonymous structs, after a cleanup
to the expression parsing code.
I was perfectly wrong in my assumptions about the cause of the bug, and
after some more digging, I think I've tracked it down to a section of
code in `DWARFASTParserClang::ParseTypeFromDWARF`.


(DWARFASTParserClang::ParseTypeFromDwarf:254)
```
switch (tag)
{
   case DW_TAG_typedef:
   // Try to parse a typedef from the DWO file first as modules
   // can contain typedef'ed structures that have no names like:
   //
   //  typedef struct { int a; } Foo;
   //
   // In this case we will have a structure with no name and a
   // typedef named "Foo" that points to this unnamed structure.
   // The name in the typedef is the only identifier for the
struct, // so always try to get typedefs from DWO files if possible.
   //
   // The type_sp returned will be empty if the typedef doesn't
exist // in a DWO file, so it is cheap to call this function just to
check. //
   // If we don't do this we end up creating a TypeSP that says
this // is a typedef to type 0x123 (the DW_AT_type value would be 0x123
   // in the DW_TAG_typedef), and this is the unnamed structure
type. // We will have a hard time tracking down an unnammed structure
   // type in the module DWO file, so we make sure we don't get
into // this situation by always resolving typedefs from the DWO file.
   type_sp = ParseTypeFromDWO(die, log);
   if (type_sp)
   return type_sp;
   LLVM_FALLTHROUGH
```

In my case, the type information for the typedef is included within the
main executable's DWARF rather than an external .dwo file (snippet from
the DWARF included the end of this message), and therefore the `case`
for `DW_TAG_typedef` falls through as `ParseTypeFromDWO` returns a NULL
value.


As this is code I'm not familiar with, I'd appreciate if any one on the
list was able to give some guidance as to the best way to resolve this
issue, so that `ClangExpressionDeclMap::FindExternalVisibleDecls` can
correctly resolve calls to functions taking typedef names to anonymous
structs. I'm happy to take a whack at implementing this feature, but
I'm a bit stuck as to how to resolve this type given the current DIE
object.

Any help or guidance on where to start with this would be really
helpful.

All the best

Luke





This is a snippet from the output of llvm-dwarfdump on the above code
example.

`g++ -g main.cpp && llvm-dwarfdump a.out | grep DW_TAG_typedef -A 35`
---

Re: [lldb-dev] DWARFASTParserClang and DW_TAG_typedef for anonymous structs

2016-03-10 Thread Luke Drummond via lldb-dev 
02: 9160: 
DW_OP_fbreg -32





The DWARFASTParserClang class is responsible for making up a clang type in the 
clang::ASTContext for this typedef. What will happen in the code where the flow falls 
through is the we will make a lldb_private::Type that says "I am a typedef to type 
whose user ID is 0x002d (in your example)". A NULL pointer should not be 
returned from the DWARFASTParserClang::ParseTypeFromDWARF() function. If it is, please 
step through and figure out why. I compiled your example and did the following:


% lldb a.out
(lldb) b main
(lldb) r
Process 89808 launched: '/private/tmp/a.out' (x86_64)
Process 89808 stopped
* thread #1: tid = 0xf7473, 0x00010fa3 a.out main + 19, stop reason = 
breakpoint 1.1, queue = com.apple.main-thread
 frame #0: 0x00010fa3 a.out main + 19 at main.c:15
12  int main()
13  {
14 my_untagged_struct s;
-> 15   myfunc();
16 return 0;
17  }
(lldb) p myfunc()
(lldb)

So I was able to call this function. Are you not able to call it?


I tried compiling with standard C99, and as you note, this works fine; 
however, C++ fails:


$ lldb a.out -o 'b 15' -o 'process launch'
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) b 15
Breakpoint 1: where = a.out`main + 8 at main.cpp:15, address = 
0x00400516

(lldb) process launch
Process 18718 stopped
* thread #1: tid = 18718, 0x00400516 a.out`main + 8 at 
main.cpp:15, name = 'a.out', stop reason = breakpoint 1.1

frame #0: 0x00400516 a.out`main + 8 at main.cpp:15

Process 18718 launched: '/tmp/a.out' (x86_64)
(lldb) expr myfunc()
error: Couldn't lookup symbols:
  myfunc($_0*)
(lldb)




Likewise if I step into this function I can see the variable:

(lldb) s
(lldb) fr var s
(my_untagged_struct *) s = 0x7fff5fbff8d0
(lldb) fr var *s
(my_untagged_struct) *s = (i = 0, f = 3.141)


This does indeed seem to work

(lldb) s
Process 18769 stopped
* thread #1: tid = 18769, 0x004004f5 
a.out`myfunc(s=0x7fffe2b0) + 8 at main.cpp:8, name = 'a.out', 
stop reason = step in
frame #0: 0x004004f5 a.out`myfunc(s=0x7fffe2b0) + 8 at 
main.cpp:8

(lldb) fr var s
(my_untagged_struct *) s = 0x7fffe2b0
(lldb) fr var *s
(my_untagged_struct) *s = (i = -7264, f = 
0.459163468)

(lldb)



So to sum up: when we parse the DW_TAG_typedef in 
DWARFASTParserClang::ParseTypeFromDWARF(), we should return a valid TypeSP that 
contains a valid pointer. If that isn't happening, that is a bug. Feel free to 
send me the example binary and I can figure things out if you have any trouble. 
I wrote all of this code so I am quite familiar with it.



I've confirmed you're absolutely right about returning a non-null TypeSP 
after fallthrough in DWARFASTParserClang::ParseTypeFromDWARF, but it 
seems that with an empty name it doesn't allow clang to resolve the 
type, failing to locate mangled function as the typename is wrong 
(_Z6myfuncP3$_0).


A colleague took a look at this today, and as a quick sanity test, threw 
together this hack:


--- a/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -553,6 +553,19 @@ DWARFASTParserClang::ParseTypeFromDWARF (const 
SymbolContext& sc,

 }
 }

+{
+uint32_t list_size = type_list->GetSize();
+for (uint32_t i = 0; i < list_size; ++i)
+{
+TypeSP t = type_list->GetTypeAtIndex(i);
+if (t->IsTypedef())
+{
+   type_name_const_str = t->GetName();
+   type_name_cstr = t->GetName().AsCString();
+}
+}
+    }


It seems to fix our problem here and expression evaluation works again 
for the presented case, but unfortunately, a few other tests break, 
which is a little frustrating. If you have time to take another look at 
why this might be the case, it'd be very much appreciated.


I've attached an example Mac binary of this issue in action built with 
an older Apple clang++, (it's simply the test above) but the result is 
the same for me on Linux with upstream clang++ and g++5.3, so I don't 
think the age of the compiler is a problem here.


Thanks again

Luke


Greg Clayton



On Mar 9, 2016, at 3:54 PM, luke Drummond via lldb-dev 
<lldb-dev@lists.llvm.org> wrote:

Hi All

I'm hoping that someone might be able to give me some direction
regarding `Type` resolution from DWARF informationfor functions taking
anonymous structs hidden behind a typedef

e.g.

```
typedef struct {
int i;
float f;
} my_untagged_struct;

void __attribute__(

[lldb-dev] DWARFASTParserClang and DW_TAG_typedef for anonymous structs

2016-03-09 Thread luke Drummond via lldb-dev 
Hi All

I'm hoping that someone might be able to give me some direction
regarding `Type` resolution from DWARF informationfor functions taking
anonymous structs hidden behind a typedef

e.g.

```
typedef struct {
int i;
float f;
} my_untagged_struct;

void __attribute__((noinline)) myfunc(my_untagged_struct *s)
{
s->i = 0;
s->f = 3.14f;
}

int main()
{
my_untagged_struct s;
myfunc();
return 0;
}

```

I [recently reported a
bug](https://llvm.org/bugs/show_bug.cgi?id=26790) relating to the
clang expression evaluator no longer being able to resolve calls to
functions with arguments to typedefed anonymous structs, after a cleanup
to the expression parsing code.
I was perfectly wrong in my assumptions about the cause of the bug, and
after some more digging, I think I've tracked it down to a section of
code in `DWARFASTParserClang::ParseTypeFromDWARF`.


(DWARFASTParserClang::ParseTypeFromDwarf:254)
```
switch (tag)
{
case DW_TAG_typedef:
// Try to parse a typedef from the DWO file first as modules
// can contain typedef'ed structures that have no names like:
//
//  typedef struct { int a; } Foo;
//
// In this case we will have a structure with no name and a
// typedef named "Foo" that points to this unnamed structure.
// The name in the typedef is the only identifier for the
struct, // so always try to get typedefs from DWO files if possible.
//
// The type_sp returned will be empty if the typedef doesn't
exist // in a DWO file, so it is cheap to call this function just to
check. //
// If we don't do this we end up creating a TypeSP that says
this // is a typedef to type 0x123 (the DW_AT_type value would be 0x123
// in the DW_TAG_typedef), and this is the unnamed structure
type. // We will have a hard time tracking down an unnammed structure
// type in the module DWO file, so we make sure we don't get
into // this situation by always resolving typedefs from the DWO file.
type_sp = ParseTypeFromDWO(die, log);
if (type_sp)
return type_sp;
LLVM_FALLTHROUGH
```

In my case, the type information for the typedef is included within the
main executable's DWARF rather than an external .dwo file (snippet from
the DWARF included the end of this message), and therefore the `case`
for `DW_TAG_typedef` falls through as `ParseTypeFromDWO` returns a NULL
value.


As this is code I'm not familiar with, I'd appreciate if any one on the
list was able to give some guidance as to the best way to resolve this
issue, so that `ClangExpressionDeclMap::FindExternalVisibleDecls` can
correctly resolve calls to functions taking typedef names to anonymous
structs. I'm happy to take a whack at implementing this feature, but
I'm a bit stuck as to how to resolve this type given the current DIE
object.

Any help or guidance on where to start with this would be really
helpful.

All the best

Luke





This is a snippet from the output of llvm-dwarfdump on the above code
example.

`g++ -g main.cpp && llvm-dwarfdump a.out | grep DW_TAG_typedef -A 35`


0x005c:   DW_TAG_typedef [6]  
DW_AT_name [DW_FORM_strp]
( .debug_str[0x0069] = "my_untagged_struct") DW_AT_decl_file
[DW_FORM_data1] ("/home/luke/main.cpp") DW_AT_decl_line
[DW_FORM_data1] (4) DW_AT_type [DW_FORM_ref4]   (cu +
0x002d => {0x002d})

0x0067:   DW_TAG_subprogram [7] *
DW_AT_external [DW_FORM_flag_present]   (true)
DW_AT_name [DW_FORM_strp]
( .debug_str[0x0006] = "myfunc") DW_AT_decl_file
[DW_FORM_data1] ("/home/luke/main.cpp") DW_AT_decl_line
[DW_FORM_data1] (6) DW_AT_linkage_name [DW_FORM_strp]
( .debug_str[0x005d] = "_Z6myfuncP18my_untagged_struct")
DW_AT_low_pc [DW_FORM_addr] (0x00400566) DW_AT_high_pc
[DW_FORM_data8] (0x0026) DW_AT_frame_base
[DW_FORM_exprloc]   (<0x1> 9c ) DW_AT_Unknown_2117
[DW_FORM_flag_present]  (true) DW_AT_sibling
[DW_FORM_ref4]  (cu + 0x0095 => {0x0095})

0x0088: DW_TAG_formal_parameter [8]  
  DW_AT_name [DW_FORM_string]   ("s")
  DW_AT_decl_file [DW_FORM_data1]
("/home/luke/main.cpp") DW_AT_decl_line [DW_FORM_data1] (6)
  DW_AT_type [DW_FORM_ref4] (cu + 0x0095 =>
{0x0095}) DW_AT_location [DW_FORM_exprloc]  (<0x2> 91 68 )

0x0094: NULL

0x0095:   DW_TAG_pointer_type [9]  
DW_AT_byte_size [DW_FORM_data1] (0x08)
DW_AT_type [DW_FORM_ref4]   (cu + 0x005c =>
{0x005c})

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

Re: [lldb-dev] Custom expression evaluation target options

2015-12-04 Thread Luke Drummond via lldb-dev 

Hi

On 03/12/15 18:02, Greg Clayton wrote:

Each expression has a language so we should be able to get the Language* for 
renderscript:


 lldb_private::Language* language = lldb_private::Language::FindPlugin 
(m_expr.GetLanguage());

Then you can add a new virtual class on lldb_private::Language that can get any 
additional compiler flags needed for expressions and just make it work? The 
renderscript language would set the appropriate ABI flags needed?


Thanks very much for clarifying my suspicion. I was working on a very 
similar implementation to this, but your way is cleaner, so I'll go 
ahead and prepare a patch.


All the Best

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