Re: [lldb-dev] clang::VersionTuple

[Pavel Labath via lldb-dev]

Thanks. I am going to submit the patch then.

On Fri, 15 Jun 2018 at 19:56, Jim Ingham  wrote:
> > On Jun 15, 2018, at 3:44 AM, Pavel Labath via lldb-dev 
> >  wrote:
> >
> > Hello again,
> >
> > Just a quick update on the state of this.
> >
> > I've managed to move VersionTuple from clang to llvm. I've also
> > created  to switch over our version
> > handling to that class.
> >
> > Could I interest anyone in taking a quick look at the patch?
>
>
> Somehow I can’t log into Phabricator from home so I can’t comment right now, 
> but I took a look.
>
> In some of your changes in the SB files you do:
>
>   if (PlatformSP platform_sp = GetSP())
> version = platform_sp->GetOSVersion();
>
> I don’t like putting initializers in if statements like this because I always 
> have to think twice about whether you meant “==“.  Moreover, all of the 
> surrounding code does it differently:
>
>   PlatformSP platform_sp = GetSP()
>   if (platform_sp)
> version = platform_sp->GetOSVersion();
>
> so switching to the other form in a couple of places only kinda forces the 
> double-take.  But that’s a little nit.

I've rechecked the llvm style guide. It doesn't say anything about
this particular issue, but this syntax is used throughout the examples
demonstrating other things.

What I like about this syntax is that it makes it clear that the
variable has no meaning outside of the if block, which is the same
reason we declare variables inside the for() statement. But those are
microscopic details I'd leave to the discretion of whoever is writing
the code.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] clang::VersionTuple

[Zachary Turner via lldb-dev]

+1 for limiting the scope of a variable as much as possible
On Mon, Jun 18, 2018 at 7:57 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Thanks. I am going to submit the patch then.
>
> On Fri, 15 Jun 2018 at 19:56, Jim Ingham  wrote:
> > > On Jun 15, 2018, at 3:44 AM, Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > >
> > > Hello again,
> > >
> > > Just a quick update on the state of this.
> > >
> > > I've managed to move VersionTuple from clang to llvm. I've also
> > > created  to switch over our version
> > > handling to that class.
> > >
> > > Could I interest anyone in taking a quick look at the patch?
> >
> >
> > Somehow I can’t log into Phabricator from home so I can’t comment right
> now, but I took a look.
> >
> > In some of your changes in the SB files you do:
> >
> >   if (PlatformSP platform_sp = GetSP())
> > version = platform_sp->GetOSVersion();
> >
> > I don’t like putting initializers in if statements like this because I
> always have to think twice about whether you meant “==“.  Moreover, all of
> the surrounding code does it differently:
> >
> >   PlatformSP platform_sp = GetSP()
> >   if (platform_sp)
> > version = platform_sp->GetOSVersion();
> >
> > so switching to the other form in a couple of places only kinda forces
> the double-take.  But that’s a little nit.
>
> I've rechecked the llvm style guide. It doesn't say anything about
> this particular issue, but this syntax is used throughout the examples
> demonstrating other things.
>
> What I like about this syntax is that it makes it clear that the
> variable has no meaning outside of the if block, which is the same
> reason we declare variables inside the for() statement. But those are
> microscopic details I'd leave to the discretion of whoever is writing
> the code.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

[Greg Clayton via lldb-dev]

> On Jun 15, 2018, at 1:48 PM, Pavel Labath  wrote:
> 
> On Fri, 15 Jun 2018 at 20:14, David Blaikie  wrote:
>> 
>> How do you handle name lookup for nested classes? They have the same problem 
>> (they don't appear in all definitions) - don't appear in all descriptions of 
>> the outer/parent class. (in theory we could ensure there's always at least a 
>> declaration of the nested class - but we don't even do that if the nested 
>> class is unused)
>> 
>> Is it just the case that Clang doesn't mind you adding a new nested class 
>> but it does mind you adding a new member function template? If so, maybe we 
>> could change Clang to support adding new member function templates instead 
>> of extending DWARF?
> 
> 
> I was thinking about the same thing. It seems to me that this could be
> viewed as a deficiency of our implementation of dwarf parsing. (It's a
> pretty understandable deficiency, given that we are based on clang
> (compiler), and it thinks of the types in the same way as C++ does --
> incomplete; or complete with template members and all). However, these
> template member functions should not impact anything "important" in
> the class (data member layout, vtables, ...) so one could conceivably
> have an implementation which allows member addition on the fly. And in
> this case the existing accelerator tables would work perfectly -- we
> would get a query "does this class have method X", we would look at
> the accel table, and it would point us straight to X. However, I have
> no idea how hard would it be to fit this scheme into the existing
> clang/lldb design.

For a little background on how the DWARF parsing works. When anything has a 
type "class A" in LLDB (variable, method in class A, etc), we first create a 
forward declaration to class A in the clang AST. Each symbol file installs 
itself as an external AST source that can complete any types when requested. 
This uses the functionality that mimics each symbol file being a precompiled 
header. Since we have an external AST source, clang can ask for the type to be 
completed at any time (just like clang does with PCH files), which will call 
back into the external AST source and cause the type to be completed. 

In LLDB, we have 3 distinct states of a type: forward declaration to type, 
completed type, the type we need for layout. If a variable has a type "class 
A*", then when displaying this variable in the output of "frame var", we don't 
need to know the full definition of class A. If the user expands a type in say 
an IDE variable view or types an expression that results in a class A instance 
or reference, we will get the complete version of the type. When we are making 
other types that include class A through inheritance or as a member variable, 
we may or may not need get the full definition for class A. For example if we 
have a "class A* m_a_ptr;" member variable, we don't need to know about A since 
we only need to know what type we need in order to layout the type which is a 
pointer here. If we inherit from class A or have a "class A m_a;" then the 
layout type needed here would be the full type. So we are very careful to only 
expand the type when and if needed in LLDB. 

That being said we currently only have two versions of the type as far as clang 
know: forward and complete. I think this is how clang expects things to be as 
well. So the above approach could work as long as we can teach clang to ask the 
external AST source about addition names when doing method lookups, but that 
will take some clang modifications that will probably only need to be enabled 
in debugger mode. Also if we did add this ability, we will want to limit it to 
classes that have templated functions we don't want to always ask a class we 
have completed to continually look for things when the user types an expression 
wrong like "a.this_method_never_will_exist_in_a()". Maybe that is ok though.

If we are able to make the above approach work, then there will need to be an 
additional fix where we would need to teach AST importer to be able to compare 
two classes and ignore any template methods when doing the compare when in 
debugger mode only. We might have two shared libraries that each have a class 
A, one with one specialized function and one with another, and when one or both 
of those get imported into the expression or target AST, they would need to 
merge the type correctly when importing it. Right now if there are two class 
trying be to imported at the same decl context layer the import will fail if 
the class exists at the same level and isn't exactly the same. 

So quite a bit of clang work if we want to make this work.

Each symbol file installs itself as an external AST source so if we wanted to 
add the template member functions on the fly, hopefully we would get a request 
that says in the DeclContext "class A" what is "Foo" if you type something like:

A a;
(lldb) a.Foo()

But I am not sure what clang will do if it already thi

Re: [lldb-dev] multiple NameErrors on lldb startup, doesn't seem to affect lldb performance

[Greg Clayton via lldb-dev]

Run this in the terminal:

% pip install six

Let me know if that fixes it.

Greg


> On Jun 15, 2018, at 1:36 PM, Peter Rowat via lldb-dev 
>  wrote:
> 
> Here is what happens:
> 
> 
>  prowat% lldb modTS
> (lldb) target create "modTS"
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/__init__.py",
>  line 98, in 
> import six
> ImportError: No module named six
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'run_one_line' is not defined
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'run_one_line' is not defined
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'run_one_line' is not defined
> Traceback (most recent call last):
> ..
> ..
> ..  (at least 100 repetitions) ..
> ..
> ..
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'run_one_line' is not defined
> Current executable set to 'modTS' (x86_64).
> (lldb)
> 
> ===
> Exactly the same output appears when lldb is started by:
> ==
> (lldb) process attach -n modTS
> 
> ==
>  prowat% lldb -v
> lldb-902.0.79.7
>   Swift-4.1
> ===
> 
> This is a nuisance but LLDB is still usable.
>  
> 
> OSX 10.13
> Peter 
> 
> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

[via lldb-dev]

> Greg wrote:
> > Pavel wrote:
> > That said, having DWARF be able to represent the template member
> > functions in an abstract way also sounds like nice thing to have from
> > a debug info format.
> 
> Yes, that would be great, but will require DWARF changes and is much more
> long term.

I'm curious what utility this has, other than tidying up the Clang AST
interface part (because you know what templates exist inside the class).
I mean, you can't instantiate new functions; and if you're trying to
call an existing instance, you have to go find it anyway, in whichever
CU it happens to have been instantiated.

Feel free to start a new thread if this is straying too far from the
discussion that already strayed from the original topic. :-)
Thanks,
--paulr

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

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

[Greg Clayton via lldb-dev]

> On Jun 18, 2018, at 9:54 AM,  
>  wrote:
> 
>> Greg wrote:
>>> Pavel wrote:
>>> That said, having DWARF be able to represent the template member
>>> functions in an abstract way also sounds like nice thing to have from
>>> a debug info format.
>> 
>> Yes, that would be great, but will require DWARF changes and is much more
>> long term.
> 
> I'm curious what utility this has, other than tidying up the Clang AST
> interface part (because you know what templates exist inside the class).
> I mean, you can't instantiate new functions; and if you're trying to
> call an existing instance, you have to go find it anyway, in whichever
> CU it happens to have been instantiated.
> 
> Feel free to start a new thread if this is straying too far from the
> discussion that already strayed from the original topic. :-)

I do agree. Probably no one else will want/need this in DWARF except us as I 
don't believe anyone else is re-creating compiler types with DWARF. Not that I 
don't think it is a good idea for debuggers to do as it allows the compiler to 
be used in the debugger. That being said, we should probably look for solutions 
that are better for all DWARF clients or just fix things in our debugger.


> Thanks,
> --paulr
> 

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

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

[Jan Kratochvil via lldb-dev]

On Mon, 18 Jun 2018 18:57:07 +0200, Greg Clayton wrote:
> I do agree. Probably no one else will want/need this in DWARF except us as
> I don't believe anyone else is re-creating compiler types with DWARF.

GDB-GCC try to copy the LLDB approach:
https://sourceware.org/gdb/wiki/GCCCompileAndExecute


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

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

[Eric Christopher via lldb-dev]

On Mon, Jun 18, 2018 at 9:57 AM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
>
> > On Jun 18, 2018, at 9:54 AM,  <
> paul.robin...@sony.com> wrote:
> >
> >> Greg wrote:
> >>> Pavel wrote:
> >>> That said, having DWARF be able to represent the template member
> >>> functions in an abstract way also sounds like nice thing to have from
> >>> a debug info format.
> >>
> >> Yes, that would be great, but will require DWARF changes and is much
> more
> >> long term.
> >
> > I'm curious what utility this has, other than tidying up the Clang AST
> > interface part (because you know what templates exist inside the class).
> > I mean, you can't instantiate new functions; and if you're trying to
> > call an existing instance, you have to go find it anyway, in whichever
> > CU it happens to have been instantiated.
> >
> > Feel free to start a new thread if this is straying too far from the
> > discussion that already strayed from the original topic. :-)
>
> I do agree. Probably no one else will want/need this in DWARF except us as
> I don't believe anyone else is re-creating compiler types with DWARF. Not
> that I don't think it is a good idea for debuggers to do as it allows the
> compiler to be used in the debugger. That being said, we should probably
> look for solutions that are better for all DWARF clients or just fix things
> in our debugger.
>
>
Oh, I've seen DWARF used outside of lldb's context to reconstruct types - I
also think it's a fairly legitimate use of debug info. If we can make it
easier to reconstruct the actual program...

-eric


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

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

[David Blaikie via lldb-dev]

On Mon, Jun 18, 2018 at 9:54 AM  wrote:

> > Greg wrote:
> > > Pavel wrote:
> > > That said, having DWARF be able to represent the template member
> > > functions in an abstract way also sounds like nice thing to have from
> > > a debug info format.
> >
> > Yes, that would be great, but will require DWARF changes and is much more
> > long term.
>
> I'm curious what utility this has, other than tidying up the Clang AST
> interface part (because you know what templates exist inside the class).
> I mean, you can't instantiate new functions; and if you're trying to
> call an existing instance, you have to go find it anyway, in whichever
> CU it happens to have been instantiated.
>

A couple of questionable reasons:

1) name/overload resolution - having the names of functions you can't call
(because they've been inlined away, never instantiated, etc) means that if
a debugger is evaluating an expression it won't accidentally resolve a call
to a different function from the one that would've been used in the source
language. (eg: a class with foo(int) and foo(T) - if you call foo(true) -
but the debugger doesn't know any foo(T) exists, so it calls foo(int),
which could be varying degrees of unfortunate)

This could happen for any function though, and it'd certainly be
impractical to include all function declarations (especially for
non-members), all types, etc, to ensure that all names are available to
validate any ambiguities, etc.

2) Possible that there are libraries linked in that themselves don't have
debug info - but include specializations of a template (or definitions of
any declared function, really) - so having the debug info could be used to
know about those functions (given at least Itanium mangling, though - I'm
not sure the debug info would be necessary, maybe looking at the mangled
name would be sufficient for a debugger to know "oh, this function is a
member of this class and has these parameter types" - hmm, guess it
wouldn't know the return type without debug info, perhaps)


>
> Feel free to start a new thread if this is straying too far from the
> discussion that already strayed from the original topic. :-)
> Thanks,
> --paulr
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 21459] CMake does not check for libedit

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=21459

Saleem Abdulrasool  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||compn...@compnerd.org

--- Comment #2 from Saleem Abdulrasool  ---
SVN r333041 and the follow up SVN r333863 should address this.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 21459] CMake does not check for libedit

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=21459

Saleem Abdulrasool  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |compn...@compnerd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] LLVM Bay Area Social July poll

[Chandler Carruth via lldb-dev]

Looks like 3:1 for having the social on July 12th... George, want to
officially call it (after confirming we can move w/ our lovely restaurant)?

On Thu, Jun 14, 2018 at 2:38 PM Chandler Carruth 
wrote:

> Twitter poll should be up:
> https://twitter.com/chandlerc1024/status/1007376443762880513
>
> (Why twitter? I'm lazy and know how to do it... and hey, I always love
> getting more folks on my twitter ;])
>
> On Thu, Jun 14, 2018 at 11:35 PM George Burgess IV via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> Hello all!
>>
>> I've received a few concerns about the date of the upcoming bay area LLVM
>> social. In particular, the 5th of July is a holiday for some people, others
>> won't be in town, etc.
>>
>> So, I was wondering what peoples' thoughts are on moving next month's
>> social to July 12th.
>>
>> Chandler volunteered to make a Twitter poll for this; I'll let him link
>> it.
>>
>> To be clear: this is just for July. Socials in August/September/... are
>> still planned for the first Thursday of their respective months.
>>
>> Any thoughts appreciated.
>>
>> Thanks!
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] LLVM Bay Area Social July poll

[George Burgess IV via lldb-dev]

> George, want to officially call it (after confirming we can move w/ our
lovely restaurant)?

WFM, and Tied House appears happy with the move. So, July's social is
officially on the 12th now.

I'll send out an email at the "regular" time to remind people that this
social has been moved.

Thanks, everyone!

On Mon, Jun 18, 2018 at 3:01 PM Chandler Carruth 
wrote:

> Looks like 3:1 for having the social on July 12th... George, want to
> officially call it (after confirming we can move w/ our lovely restaurant)?
>
> On Thu, Jun 14, 2018 at 2:38 PM Chandler Carruth 
> wrote:
>
>> Twitter poll should be up:
>> https://twitter.com/chandlerc1024/status/1007376443762880513
>>
>> (Why twitter? I'm lazy and know how to do it... and hey, I always love
>> getting more folks on my twitter ;])
>>
>> On Thu, Jun 14, 2018 at 11:35 PM George Burgess IV via cfe-dev <
>> cfe-...@lists.llvm.org> wrote:
>>
>>> Hello all!
>>>
>>> I've received a few concerns about the date of the upcoming bay area
>>> LLVM social. In particular, the 5th of July is a holiday for some people,
>>> others won't be in town, etc.
>>>
>>> So, I was wondering what peoples' thoughts are on moving next month's
>>> social to July 12th.
>>>
>>> Chandler volunteered to make a Twitter poll for this; I'll let him link
>>> it.
>>>
>>> To be clear: this is just for July. Socials in August/September/... are
>>> still planned for the first Thursday of their respective months.
>>>
>>> Any thoughts appreciated.
>>>
>>> Thanks!
>>> ___
>>> cfe-dev mailing list
>>> cfe-...@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 37840] New: incorrect results of expression evaluation

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=37840

Bug ID: 37840
   Summary: incorrect results of expression evaluation
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: tianxiao...@gmail.com
CC: llvm-b...@lists.llvm.org

Created attachment 20442
  --> https://bugs.llvm.org/attachment.cgi?id=20442&action=edit
scripts to reproduce the issue.

## Overview

lldb command print/expression produces incorrect values.
This issue can be reproduced with lldb 7.0.

~~~
$ lldb -version
lldb version 7.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision
334970)
  clang revision 334970
  llvm revision 334970
~~~

## Input Program


#include 
#include 
int main() {
  int32_t g_1974 = 1482617779;
  int16_t g_159  = -7666;
  printf("%d\n", g_1974 & g_159); // break here and see the result of (g_1974 &
g_159)
  return 0;
}
~~~


## Reproduce Steps

The attached zip file contains files that can reproduce the issue.

1. See results of lldb by running `run-lldb.sh`.

(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) command source -s 0 'lldb-cmds.txt'
Executing commands in '/home/t/bug1/lldb-cmds.txt'.
(lldb) breakpoint set -file test.c -line 7
Breakpoint 1: where = a.out`main + 45 at test.c:7, address = 0x00400553
(lldb) process launch
1482613250
Process 20892 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00400553 a.out`main at test.c:7
   4  int32_t g_1974 = 1482617779;
   5  int16_t g_159  = -7666;
   6  printf("%d\n", g_1974 & g_159);
-> 7  return 0;
   8}

Process 20892 launched: '/home/t/bug1/a.out' (x86_64)
(lldb) print g_1974
(int32_t) $0 = 1482617779
(lldb) print g_159
(int16_t) $1 = -7666
(lldb) print (g_1974 & g_159)
(int) $2 = 57858 <--- HERE SHOULD BE 1482613250

2. Run `run-gdb.sh` for gdb.

Breakpoint 1 at 0x400553: file test.c, line 7.
1482613250

Breakpoint 1, main () at test.c:7
7 return 0;
$1 = 1482617779
$2 = -7666
$3 = 1482613250

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev