Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Greg Clayton via lldb-commits 
If you check the expression log, you will see the printf() function declaration 
and any others we add:

(lldb) log enable lldb expr
(lldb) 2+3

...
#ifndef NULL
#define NULL (__null)
#endif
#ifndef Nil
#define Nil (__null)
#endif
#ifndef nil
#define nil (__null)
#endif
#ifndef YES
#define YES ((BOOL)1)
#endif
#ifndef NO
#define NO ((BOOL)0)
#endif
typedef __INT8_TYPE__ int8_t;
typedef __UINT8_TYPE__ uint8_t;
typedef __INT16_TYPE__ int16_t;
typedef __UINT16_TYPE__ uint16_t;
typedef __INT32_TYPE__ int32_t;
typedef __UINT32_TYPE__ uint32_t;
typedef __INT64_TYPE__ int64_t;
typedef __UINT64_TYPE__ uint64_t;
typedef __INTPTR_TYPE__ intptr_t;
typedef __UINTPTR_TYPE__ uintptr_t;
typedef __SIZE_TYPE__ size_t;
typedef __PTRDIFF_TYPE__ ptrdiff_t;
typedef unsigned short unichar;
extern "C"
{
int printf(const char * __restrict, ...);
}

typedef signed char BOOL;


void   
$__lldb_expr(void *$__lldb_arg)  
{  
;
/*LLDB_BODY_START*/
2+3;
/*LLDB_BODY_END*/
}  

...



> On Mar 13, 2018, at 11:04 AM, Davide Italiano  wrote:
> 
> On Tue, Mar 13, 2018 at 10:57 AM, Greg Clayton  wrote:
>> 
>> 
>>> On Mar 13, 2018, at 10:37 AM, Davide Italiano via lldb-commits 
>>>  wrote:
>>> 
>>> An alternative proposed by Fred which is an OK middle ground IMHO is
>>> that of not inserting a decl for the unmangled name, but treat this
>>> symbol always as-it-is.
>>> i.e. if we have a symbol _Znwm in some object, we don't insert a decl
>>> for `operator new(unsigned long)` but for _Znwm itself.
>>> 
>>> Greg, Jason, would that work for you guys?
>> 
>> I would be ok with that.
>> 
> 
> I'm going to send a review for this soon.
> 
> Best,
> 
> --
> Davide

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

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Davide Italiano via lldb-commits 
On Tue, Mar 13, 2018 at 11:17 AM, Greg Clayton  wrote:
> If you check the expression log, you will see the printf() function 
> declaration and any others we add:
>
> (lldb) log enable lldb expr
> (lldb) 2+3
>
> ...
> #ifndef NULL
> #define NULL (__null)
> #endif
> #ifndef Nil
> #define Nil (__null)
> #endif
> #ifndef nil
> #define nil (__null)
> #endif
> #ifndef YES
> #define YES ((BOOL)1)
> #endif
> #ifndef NO
> #define NO ((BOOL)0)
> #endif
> typedef __INT8_TYPE__ int8_t;
> typedef __UINT8_TYPE__ uint8_t;
> typedef __INT16_TYPE__ int16_t;
> typedef __UINT16_TYPE__ uint16_t;
> typedef __INT32_TYPE__ int32_t;
> typedef __UINT32_TYPE__ uint32_t;
> typedef __INT64_TYPE__ int64_t;
> typedef __UINT64_TYPE__ uint64_t;
> typedef __INTPTR_TYPE__ intptr_t;
> typedef __UINTPTR_TYPE__ uintptr_t;
> typedef __SIZE_TYPE__ size_t;
> typedef __PTRDIFF_TYPE__ ptrdiff_t;
> typedef unsigned short unichar;
> extern "C"
> {
> int printf(const char * __restrict, ...);
> }
>
> typedef signed char BOOL;
>
>
> void
> $__lldb_expr(void *$__lldb_arg)
> {
> ;
> /*LLDB_BODY_START*/
> 2+3;
> /*LLDB_BODY_END*/
> }
>
> ...
>

I checked it works also for strtok(), which I don't think we add.

Best,

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

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Davide Italiano via lldb-commits 
On Tue, Mar 13, 2018 at 10:56 AM, Greg Clayton  wrote:
>
>
> On Mar 13, 2018, at 10:25 AM, Davide Italiano via lldb-commits
>  wrote:
>
> On Tue, Mar 13, 2018 at 9:59 AM, Frédéric Riss via lldb-commits
>  wrote:
>
>
>
> On Mar 12, 2018, at 6:40 PM, Davide Italiano via lldb-commits
>  wrote:
>
> Author: davide
> Date: Mon Mar 12 18:40:00 2018
> New Revision: 327356
>
> URL: http://llvm.org/viewvc/llvm-project?rev=327356=rev
> Log:
> [ExpressionParser] Fix crash when evaluating invalid expresssions.
>
> Typical example, illformed comparisons (operator== where LHS and
> RHS are not compatible). If a symbol matched `operator==` in any
> of the object files lldb inserted a generic function declaration
> in the ASTContext on which Sema operates. Maintaining the AST
> context invariants is fairly tricky and sometimes resulted in
> crashes inside clang (or assertions hit).
>
> The real reason why this feature exists in the first place is
> that of allowing users to do something like:
> (lldb) call printf("patatino")
>
> even if the debug informations for printf() is not available.
> Eventually, we might reconsider this feature in its
> entirety, but for now we can't remove it as it would break
> a bunch of users. Instead, try to limit it to non-C++ symbols,
> where getting the invariants right is hopefully easier.
>
> Now you can't do in lldb anymore
> (lldb) call _Zsomethingsomething(1,2,3)
>
> but that doesn't seem to be such a big loss.
>
>
> I’m somewhat surprised by this. My understanding of the crash you were
> investigating is that Clang crashed because we injected a Decl looking like
> this: “void operator==(…)” after finding the operator== symbol somewhere. I
> think injecting bogus C++ Decls makes no sense and it cannot really work
> anyway.
>
> On the other hand, I see no harm in injecting “_Zsomethingsomething(…)” as a
> C Decl. This can be useful, and people should be able to call raw symbols in
> their binaries. Is there no way to keep the later while preventing the
> creation of broken C++ decls?
>
>
> Thank you all for your feedback. I'll reply with a single mail to everybody.
>
> C decls can be inserted. In fact, this works, even after my changes:
>
> (lldb) call printf("patatino")
> (int) $0 = 8
>
>
> That is because we define a function prototype for printf. So please try
> another function. You always have to cast the result of a function call to a
> symbol. In this case, since you didn't get a warning, you can know that you
> didn't use a symbol...
>
>
> I always thought identifiers beginning with underscore where illegal in C.
> Here's what the standard says:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
>
> Section 7.1.3
> "All identifiers that begin with an underscore and either an uppercase
> letter or another underscore are always reserved for any use."
>
>
> And yet there are many symbols that violate this. Just because someone says
> it is so, doesn't mean it is and also if there is no enforcement, then the
> rule doesn't mean much.
>
>
> They're not quite illegal, but they're reserved, so I'm unsure how
> frequent having symbols starting with `_Z` is popular.
>
>
> It is a legal C identifier, so we need to be able to call it.
>
>
> Maybe lldb has a better way of detecting whether this is a C or a C++
> program?
>
>
> Yes with debug info, no if we only have symbol table.
>
>
> There are several constraints:
>
> 1) The object from which we're loading symbols has no debug info, so
> we can't look at the CU and just say whether it's C or C++ or
> Objective-C.
> 2) The expression parser always evaluates expressions in a C++ context
> (to the best of my understanding)
> 3) You can always mix-and-match C/C++ object files as they're just
> Mach-O or ELF objects at that point (not recommended, but I've seen
> people doing it).
>
> Do you have any thoughts on how this should be achieved?
>
>
> What are you trying to achieve?
>

We had the report of a crash where lldb was setting a conditional
breakpoint on an invalid condition (CGRect == pointer, which is,
ill-formed).
The symbol-based resolution of lldb was picking a random operator==,
inserting a generic function decl operator== in the context because it
happened to find a matching symbol somewhere in the system.

clang expects operator== to have at least one argument, so you end up
hitting this assertion in Sema.

(lldb) Assertion failed: (i < getNumParams() && "Illegal param #"),
function getParamDecl, file
/Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/clang/include/clang/AST/Decl.h,
line 2232.

So, to answer your question, Greg, I just want lldb to not inject
arbitrary C++ func decl. What do you think is the best way of
achieving this?

Best,

--
Davide
___
lldb-commits mailing list
lldb-commits@lists.llvm.org

[Lldb-commits] [lldb] r327445 - [DataFormatter] Remove dead code for the NSDictionary formatter.

2018-03-13 Thread Davide Italiano via lldb-commits 
Author: davide
Date: Tue Mar 13 13:26:38 2018
New Revision: 327445

URL: http://llvm.org/viewvc/llvm-project?rev=327445=rev
Log:
[DataFormatter] Remove dead code for the NSDictionary formatter.

I'm going to make changes in this area soon, so I figured I
could clean things a bit while I was around.

Modified:
lldb/trunk/source/Plugins/Language/ObjC/NSDictionary.cpp

Modified: lldb/trunk/source/Plugins/Language/ObjC/NSDictionary.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/ObjC/NSDictionary.cpp?rev=327445=327444=327445=diff
==
--- lldb/trunk/source/Plugins/Language/ObjC/NSDictionary.cpp (original)
+++ lldb/trunk/source/Plugins/Language/ObjC/NSDictionary.cpp Tue Mar 13 
13:26:38 2018
@@ -424,16 +424,6 @@ bool lldb_private::formatters::NSDiction
   } else if (class_name == g_Dictionary1) {
 value = 1;
   }
-  /*else if (!strcmp(class_name,"__NSCFDictionary"))
-   {
-   Status error;
-   value = process_sp->ReadUnsignedIntegerFromMemory(valobj_addr + (is_64bit ?
-   20 : 12), 4, 0, error);
-   if (error.Fail())
-   return false;
-   if (is_64bit)
-   value &= ~0x0f1fUL;
-   }*/
   else {
 auto (NSDictionary_Additionals::GetAdditionalSummaries());
 for (auto  : map) {


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

[Lldb-commits] [lldb] r327379 - Fix linux s390x build (pr36694)

2018-03-13 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Tue Mar 13 02:46:00 2018
New Revision: 327379

URL: http://llvm.org/viewvc/llvm-project?rev=327379=rev
Log:
Fix linux s390x build (pr36694)

Modified:
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_s390x.cpp

Modified: 
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_s390x.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_s390x.cpp?rev=327379=327378=327379=diff
==
--- 
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_s390x.cpp 
(original)
+++ 
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_s390x.cpp 
Tue Mar 13 02:46:00 2018
@@ -10,7 +10,7 @@
 #if defined(__s390x__) && defined(__linux__)
 
 #include "NativeRegisterContextLinux_s390x.h"
-
+#include "Plugins/Process/Linux/NativeProcessLinux.h"
 #include "lldb/Core/RegisterValue.h"
 #include "lldb/Host/HostInfo.h"
 #include "lldb/Utility/DataBufferHeap.h"


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

[Lldb-commits] [lldb] r327380 - Fix clang-3.8 build

2018-03-13 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Tue Mar 13 02:46:10 2018
New Revision: 327380

URL: http://llvm.org/viewvc/llvm-project?rev=327380=rev
Log:
Fix clang-3.8 build

clang-3.8 complains that constructor for '...' must explicitly
initialize the const member. Newer clangs and gcc seem to be fine with
this, but explicitly initializing the member does not hurt.

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

Modified: 
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp?rev=327380=327379=327380=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp 
(original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp 
Tue Mar 13 02:46:10 2018
@@ -169,7 +169,7 @@ ClangModulesDeclVendorImpl::ClangModules
 : m_diagnostics_engine(std::move(diagnostics_engine)),
   m_compiler_invocation(std::move(compiler_invocation)),
   m_compiler_instance(std::move(compiler_instance)),
-  m_parser(std::move(parser)) {}
+  m_parser(std::move(parser)), m_origin_map() {}
 
 void ClangModulesDeclVendorImpl::ReportModuleExportsHelper(
 std::set ,


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

[Lldb-commits] [PATCH] D44306: Move Args::StringToAddress to Target::EvaluateAddressExpression

2018-03-13 Thread Pavel Labath via Phabricator via lldb-commits 
labath planned changes to this revision.
labath added a comment.

Yes, that thought occurred to me almost immediately after I submitted this. 
I'll try to implement something like that instead.

Since this will be just a bunch of static functions with no state, I think we 
don't even have to put them into an existing class, but instead create a new 
file/class for holding just this. I just need to figure out a good name for 
that.


https://reviews.llvm.org/D44306



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

[Lldb-commits] [lldb] r327413 - include locale.h in IOHandler.cpp

2018-03-13 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Tue Mar 13 08:55:00 2018
New Revision: 327413

URL: http://llvm.org/viewvc/llvm-project?rev=327413=rev
Log:
include locale.h in IOHandler.cpp

This is needed for the setlocale() call, and it seems that it is not
transitively pulled in for some build configurations.

Modified:
lldb/trunk/source/Core/IOHandler.cpp

Modified: lldb/trunk/source/Core/IOHandler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/IOHandler.cpp?rev=327413=327412=327413=diff
==
--- lldb/trunk/source/Core/IOHandler.cpp (original)
+++ lldb/trunk/source/Core/IOHandler.cpp Tue Mar 13 08:55:00 2018
@@ -67,6 +67,7 @@
 #include // for assert
 #include  // for isspace
 #include  // for EINTR, errno
+#include // for setlocale
 #include // for uint32_t, UINT32_MAX
 #include  // for size_t, fprintf, feof
 #include // for strlen


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

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Jason Molenda via lldb-commits 


> On Mar 12, 2018, at 7:52 PM, Davide Italiano via lldb-commits 
>  wrote:
> 
> On Mon, Mar 12, 2018 at 7:27 PM, Jason Molenda via lldb-commits
>  wrote:
>> FWIW, we'll definitely get pushback about
>> 
>>> Now you can't do in lldb anymore
>>> (lldb) call _Zsomethingsomething(1,2,3)
>> 
>> 
>> There are clever users of lldb, often working at assembly language level 
>> without any symbolic information, who are able to correctly call a C++ 
>> mangled function by hand.  It's not something I'd want to do personally, but 
>> I'd be mad at my debugger if it gave me an error message when I told it what 
>> to do.
>> 
>> 
> 
> I understand your point. We had several discussions about this and I
> was really reluctant to push this change to begin with.

Sorry for missing out on the earlier discussions and coming in to this late.


I don't understand exactly what's going on here.  If I have a program like

extern "C"  void takefive_c(int five) {};
void takefive_cpp(int five) {}
int main () {}

compiled without debug information, I can do

(lldb) p (void)takefive_c(5)
(lldb) p (void)_Z12takefive_cppi(5)


why is the second expression any different than the first?  I'm calling a 
symbol name without any debug information, prototypes, or types at all.




> I thought about alternatives and basically I ended up realizing that
> maintaining the invariants that the AST wants Is crazytown.
> You don't need to squint too hard to see that basically nobody using
> clang does this.
> All the clang tools prefer to insert text in a source file and reparse
> it because modifying the AST in place is hard.
> It's funny that they do that because the changes they make are
> generally fairly localized, but nobody really understands what Sema
> really wants (note, the invariants are hardcoded in the Sema path).
> Injecting a generic decl in the context and crossing finger is not
> really great IMHO. It causes crashes, which, from what I understand in
> the lldb world are much worse than not being able to display
> informations (from what I can see the mantra of lldb is "the debugger
> should never crash").
> 
> So, yes, this patch is in some way picking one of two poisons. If we
> want to take a look at this again (i.e. we consider it important
> enough), then the interaction between debugger and compiler needs to
> be rethought to inject something less terrible than a generic decl.
> This is, needless to say, fairly hard because in this case you're
> getting the symbols from a Mach-O object file, so all the state you
> have is a mangled symbol name, which doesn't contain enough
> information to reconstruct the whole context. In swift we can do
> better because we have a fully-fledged type reconstruction mechanism
> (swift::ide::GetTypeFromMangledSymbolName()), and even there, we
> experienced a fair amount of pain because the path still has issues
> that need to be shaken.
> 
> tl;dr if somebody wants to rewrite this, I'll be very happy to support
> this , but I don't see a real reason to keep the feature in an
> half-baked state.
> 
> Best,
> 
> --
> Davide
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Frédéric Riss via lldb-commits 


> On Mar 12, 2018, at 6:40 PM, Davide Italiano via lldb-commits 
>  wrote:
> 
> Author: davide
> Date: Mon Mar 12 18:40:00 2018
> New Revision: 327356
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=327356=rev
> Log:
> [ExpressionParser] Fix crash when evaluating invalid expresssions.
> 
> Typical example, illformed comparisons (operator== where LHS and
> RHS are not compatible). If a symbol matched `operator==` in any
> of the object files lldb inserted a generic function declaration
> in the ASTContext on which Sema operates. Maintaining the AST
> context invariants is fairly tricky and sometimes resulted in
> crashes inside clang (or assertions hit).
> 
> The real reason why this feature exists in the first place is
> that of allowing users to do something like:
> (lldb) call printf("patatino")
> 
> even if the debug informations for printf() is not available.
> Eventually, we might reconsider this feature in its
> entirety, but for now we can't remove it as it would break
> a bunch of users. Instead, try to limit it to non-C++ symbols,
> where getting the invariants right is hopefully easier.
> 
> Now you can't do in lldb anymore
> (lldb) call _Zsomethingsomething(1,2,3)
> 
> but that doesn't seem to be such a big loss.

I’m somewhat surprised by this. My understanding of the crash you were 
investigating is that Clang crashed because we injected a Decl looking like 
this: “void operator==(…)” after finding the operator== symbol somewhere. I 
think injecting bogus C++ Decls makes no sense and it cannot really work anyway.

On the other hand, I see no harm in injecting “_Zsomethingsomething(…)” as a C 
Decl. This can be useful, and people should be able to call raw symbols in 
their binaries. Is there no way to keep the later while preventing the creation 
of broken C++ decls?

Fred

> 
> 
> Added:
>lldb/trunk/lit/Expr/Inputs/basic.cpp
>lldb/trunk/lit/Expr/TestCallCppSym.test
> Modified:
>lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
> 
> Added: lldb/trunk/lit/Expr/Inputs/basic.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Expr/Inputs/basic.cpp?rev=327356=auto
> ==
> --- lldb/trunk/lit/Expr/Inputs/basic.cpp (added)
> +++ lldb/trunk/lit/Expr/Inputs/basic.cpp Mon Mar 12 18:40:00 2018
> @@ -0,0 +1,12 @@
> +class Patatino {
> +private:
> +  long tinky;
> +
> +public:
> +  Patatino(long tinky) { this->tinky = tinky; }
> +};
> +
> +int main(void) {
> +  Patatino *a = new Patatino(26);
> +  return 0;
> +}
> 
> Added: lldb/trunk/lit/Expr/TestCallCppSym.test
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Expr/TestCallCppSym.test?rev=327356=auto
> ==
> --- lldb/trunk/lit/Expr/TestCallCppSym.test (added)
> +++ lldb/trunk/lit/Expr/TestCallCppSym.test Mon Mar 12 18:40:00 2018
> @@ -0,0 +1,6 @@
> +# RUN: %cxx %p/Inputs/basic.cpp -g -o %t && %lldb -b -s %s -- %t 2>&1 | 
> FileCheck %s
> +
> +breakpoint set --file basic.cpp --line 12
> +run
> +call (int)_Znwm(23)
> +# CHECK: error: use of undeclared identifier '_Znwm'
> 
> Modified: 
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp?rev=327356=327355=327356=diff
> ==
> --- 
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp 
> (original)
> +++ 
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp 
> Mon Mar 12 18:40:00 2018
> @@ -2072,6 +2072,15 @@ void ClangExpressionDeclMap::AddOneFunct
>   return;
> }
>   } else if (symbol) {
> +// Don't insert a generic function decl for C++ symbol names.
> +// Creating a generic function decl is almost surely going to cause 
> troubles
> +// as it breaks Clang/Sema invariants and causes crashes in clang while
> +// we're trying to evaluate the expression.
> +// This means users can't call C++ functions by mangled name when there
> +// are no debug info (as it happens for C symbol, e.g. printf()).
> +if (CPlusPlusLanguage::IsCPPMangledName(
> +symbol->GetMangled().GetMangledName().GetCString()))
> +  return;
> fun_address = symbol->GetAddress();
> function_decl = context.AddGenericFunDecl();
> is_indirect_function = symbol->IsIndirect();
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

[Lldb-commits] [lldb] r327463 - [test] Replace some references to Apple-internal bugs

2018-03-13 Thread Vedant Kumar via lldb-commits 
Author: vedantk
Date: Tue Mar 13 16:37:11 2018
New Revision: 327463

URL: http://llvm.org/viewvc/llvm-project?rev=327463=rev
Log:
[test] Replace some references to Apple-internal bugs

This removes around 10 references to Apple-internal radars. I've filed
fresh bugs on bugs.llvm.org as appropriate for open issues.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/api/multiple-debuggers/TestMultipleDebuggers.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/asan/TestReportData.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/variable_out_of_scope/TestWatchedVarHitWhenInScope.py
lldb/trunk/packages/Python/lldbsuite/test/lang/c/shared_lib/TestSharedLib.py

lldb/trunk/packages/Python/lldbsuite/test/lang/c/shared_lib_stripped_symbols/TestSharedLibStrippedSymbols.py

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/dynamic-value/TestCppValueCast.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/printf/TestPrintf.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/stl/TestSTL.py

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/unique-types/TestUniqueTypes.py

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/bitfield_ivars/TestBitfieldIvars.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/api/multiple-debuggers/TestMultipleDebuggers.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/api/multiple-debuggers/TestMultipleDebuggers.py?rev=327463=327462=327463=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/api/multiple-debuggers/TestMultipleDebuggers.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/api/multiple-debuggers/TestMultipleDebuggers.py
 Tue Mar 13 16:37:11 2018
@@ -18,17 +18,9 @@ class TestMultipleSimultaneousDebuggers(
 
 mydir = TestBase.compute_mydir(__file__)
 
+# This test case fails non-deterministically. 
 @skipIfNoSBHeaders
-@expectedFailureAll(bugnumber="rdar://30564102")
-@expectedFailureAll(
-archs="i[3-6]86",
-bugnumber="multi-process-driver.cpp creates an x64 target")
-@expectedFailureAll(
-oslist=[
-"windows",
-"linux",
-"freebsd"],
-bugnumber="llvm.org/pr20282")
+@expectedFailureAll(bugnumber="llvm.org/pr20282")
 def test_multiple_debuggers(self):
 env = {self.dylibPath: self.getLLDBLibraryEnvVal()}
 

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/asan/TestReportData.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/asan/TestReportData.py?rev=327463=327462=327463=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/asan/TestReportData.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/asan/TestReportData.py
 Tue Mar 13 16:37:11 2018
@@ -24,7 +24,7 @@ class AsanTestReportDataCase(TestBase):
 @skipIfFreeBSD  # llvm.org/pr21136 runtimes not yet available by default
 @skipIfRemote
 @skipUnlessAddressSanitizer
-@expectedFailureAll(archs=['i386'], bugnumber="rdar://28658860")
+@skipIf(archs=['i386'], bugnumber="llvm.org/PR36710")
 def test(self):
 self.build()
 self.asan_tests()

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/variable_out_of_scope/TestWatchedVarHitWhenInScope.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/variable_out_of_scope/TestWatchedVarHitWhenInScope.py?rev=327463=327462=327463=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/variable_out_of_scope/TestWatchedVarHitWhenInScope.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/variable_out_of_scope/TestWatchedVarHitWhenInScope.py
 Tue Mar 13 16:37:11 2018
@@ -18,13 +18,13 @@ class WatchedVariableHitWhenInScopeTestC
 
 mydir = TestBase.compute_mydir(__file__)
 
-#
 # This test depends on not tracking watchpoint expression hits if we have
 # left the watchpoint scope.  We will provide such an ability at some point
 # but the way this was done was incorrect, and it is unclear that for the
 # most part that's not what folks mostly want, so we have to provide a
 # clearer API to express this.
 #
+# This functionality is currently unsupported on Darwin.
 
 def setUp(self):
 # Call super's setUp().
@@ -36,7 +36,7 @@ class WatchedVariableHitWhenInScopeTestC
 
 # Test hangs due to a kernel bug, see fdfeff0f in the linux kernel for 
details
 @skipIfTargetAndroid(api_levels=list(range(25+1)), archs=["aarch64", 
"arm"])
-

[Lldb-commits] [PATCH] D44139: Update selected thread after loading mach core

2018-03-13 Thread Jason Molenda via Phabricator via lldb-commits 
jasonmolenda added a comment.

(or rather, not "conflict with the OperatingSystemPlugIn stop reason" -- but 
would make it confusing to users.  I think it might be best to remove 
ThreadMachCore::CalculateStopInfo.)


https://reviews.llvm.org/D44139



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

[Lldb-commits] [lldb] r327448 - Add a missing return in SBPlatform::IsConnected and test

2018-03-13 Thread Jim Ingham via lldb-commits 
Author: jingham
Date: Tue Mar 13 14:06:05 2018
New Revision: 327448

URL: http://llvm.org/viewvc/llvm-project?rev=327448=rev
Log:
Add a missing return in SBPlatform::IsConnected and test
for the behavior - using the fact that the Host platform
is always present & connected.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py
lldb/trunk/source/API/SBPlatform.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py?rev=327448=327447=327448=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py
 Tue Mar 13 14:06:05 2018
@@ -51,6 +51,14 @@ class PlatformPythonTestCase(TestBase):
 
 @add_test_categories(['pyapi'])
 @no_debug_info_test
+def test_host_is_connected(self):
+# We've already tested that this one IS the host platform.
+host_platform = self.dbg.GetPlatformAtIndex(0)
+self.assertTrue(host_platform.IsConnected(), "The host platform is 
always connected")
+
+
+@add_test_categories(['pyapi'])
+@no_debug_info_test
 def test_available_platform_list(self):
 """Test SBDebugger::GetNumAvailablePlatforms() and 
GetAvailablePlatformInfoAtIndex() API"""
 num_platforms = self.dbg.GetNumAvailablePlatforms()

Modified: lldb/trunk/source/API/SBPlatform.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBPlatform.cpp?rev=327448=327447=327448=diff
==
--- lldb/trunk/source/API/SBPlatform.cpp (original)
+++ lldb/trunk/source/API/SBPlatform.cpp Tue Mar 13 14:06:05 2018
@@ -271,7 +271,7 @@ void SBPlatform::DisconnectRemote() {
 bool SBPlatform::IsConnected() {
   PlatformSP platform_sp(GetSP());
   if (platform_sp)
-platform_sp->IsConnected();
+return platform_sp->IsConnected();
   return false;
 }
 


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

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Jason Molenda via lldb-commits 


> On Mar 13, 2018, at 11:51 AM, Davide Italiano via lldb-commits 
>  wrote:
> 
> We had the report of a crash where lldb was setting a conditional
> breakpoint on an invalid condition (CGRect == pointer, which is,
> ill-formed).
> The symbol-based resolution of lldb was picking a random operator==,
> inserting a generic function decl operator== in the context because it
> happened to find a matching symbol somewhere in the system.
> 
> clang expects operator== to have at least one argument, so you end up
> hitting this assertion in Sema.
> 
> (lldb) Assertion failed: (i < getNumParams() && "Illegal param #"),
> function getParamDecl, file
> /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/clang/include/clang/AST/Decl.h,
> line 2232.
> 
> So, to answer your question, Greg, I just want lldb to not inject
> arbitrary C++ func decl. What do you think is the best way of
> achieving this?
> 


I put together a repo case that might help make this clearer (attached)



repo.tar
Description: Unix tar archive



we have a test program with three translation units.  One has C++ methods and 
was built with debug info ("foo"), one has C++ methods and was built without 
debug info ("bar").  It tries calling these from lldb:


(lldb) p (void)foo('c')
in foo(char)
(lldb) p (void)foo(5)
in foo(int)
(lldb) p (void)foo(5, 5)
in foo(int, int)

We had debug info for foo(), called the correct methods.


(lldb) p (void)bar('c')
in bar(char *)
(lldb) p (void)bar(5)
in bar(char *)
(lldb) p (void)bar(5, 5)
in bar(char *)


Here, we have no debug info for bar(), so we grabbed the first bar() method we 
found and used it for all calls.  This is a problem.


(lldb) p (void)_Z3barc('c')
in bar(char)
(lldb) p (void)_Z3bari(5)
in bar(int)
(lldb) p (void)_Z3barii(5,5)
in bar(int, int)

Calling the mangled name bar()'s directly works as expected.



Davide is trying to solve that middle one.  I think the problem he was working 
on is where we had an expression using operator== and the first "decl" we found 
of this was in a no-debug-info translation unit, and that randomly chosen 
operator== was used when there WAS debug info for this operator== in a 
different translation unit in the process.

The question I have is -- should this even be allowed.  Should you be able to 
call a C++ method using a demangled name with no debug info?  I'm trying to 
think of a case where people do this today.  Clearly it does not work correctly 
today for overloaded functions.  And apparently this could be chosen over a 
debug info definition that might appear elsewhere in the process?  I didn't try 
to test that.

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

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Davide Italiano via lldb-commits 
An alternative proposed by Fred which is an OK middle ground IMHO is
that of not inserting a decl for the unmangled name, but treat this
symbol always as-it-is.
i.e. if we have a symbol _Znwm in some object, we don't insert a decl
for `operator new(unsigned long)` but for _Znwm itself.

Greg, Jason, would that work for you guys?

Thanks!

--
Davide

On Tue, Mar 13, 2018 at 10:25 AM, Davide Italiano  wrote:
> On Tue, Mar 13, 2018 at 9:59 AM, Frédéric Riss via lldb-commits
>  wrote:
>>
>>
>>> On Mar 12, 2018, at 6:40 PM, Davide Italiano via lldb-commits 
>>>  wrote:
>>>
>>> Author: davide
>>> Date: Mon Mar 12 18:40:00 2018
>>> New Revision: 327356
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=327356=rev
>>> Log:
>>> [ExpressionParser] Fix crash when evaluating invalid expresssions.
>>>
>>> Typical example, illformed comparisons (operator== where LHS and
>>> RHS are not compatible). If a symbol matched `operator==` in any
>>> of the object files lldb inserted a generic function declaration
>>> in the ASTContext on which Sema operates. Maintaining the AST
>>> context invariants is fairly tricky and sometimes resulted in
>>> crashes inside clang (or assertions hit).
>>>
>>> The real reason why this feature exists in the first place is
>>> that of allowing users to do something like:
>>> (lldb) call printf("patatino")
>>>
>>> even if the debug informations for printf() is not available.
>>> Eventually, we might reconsider this feature in its
>>> entirety, but for now we can't remove it as it would break
>>> a bunch of users. Instead, try to limit it to non-C++ symbols,
>>> where getting the invariants right is hopefully easier.
>>>
>>> Now you can't do in lldb anymore
>>> (lldb) call _Zsomethingsomething(1,2,3)
>>>
>>> but that doesn't seem to be such a big loss.
>>
>> I’m somewhat surprised by this. My understanding of the crash you were 
>> investigating is that Clang crashed because we injected a Decl looking like 
>> this: “void operator==(…)” after finding the operator== symbol somewhere. I 
>> think injecting bogus C++ Decls makes no sense and it cannot really work 
>> anyway.
>>
>> On the other hand, I see no harm in injecting “_Zsomethingsomething(…)” as a 
>> C Decl. This can be useful, and people should be able to call raw symbols in 
>> their binaries. Is there no way to keep the later while preventing the 
>> creation of broken C++ decls?
>>
>
> Thank you all for your feedback. I'll reply with a single mail to everybody.
>
> C decls can be inserted. In fact, this works, even after my changes:
>
> (lldb) call printf("patatino")
> (int) $0 = 8
>
> I always thought identifiers beginning with underscore where illegal in C.
> Here's what the standard says:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
>
> Section 7.1.3
> "All identifiers that begin with an underscore and either an uppercase
> letter or another underscore are always reserved for any use."
>
> They're not quite illegal, but they're reserved, so I'm unsure how
> frequent having symbols starting with `_Z` is popular.
>
> Maybe lldb has a better way of detecting whether this is a C or a C++ program?
>
> There are several constraints:
>
> 1) The object from which we're loading symbols has no debug info, so
> we can't look at the CU and just say whether it's C or C++ or
> Objective-C.
> 2) The expression parser always evaluates expressions in a C++ context
> (to the best of my understanding)
> 3) You can always mix-and-match C/C++ object files as they're just
> Mach-O or ELF objects at that point (not recommended, but I've seen
> people doing it).
>
> Do you have any thoughts on how this should be achieved?
>
> Best,
>
> --
> Davide
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Greg Clayton via lldb-commits 


> On Mar 13, 2018, at 10:37 AM, Davide Italiano via lldb-commits 
>  wrote:
> 
> An alternative proposed by Fred which is an OK middle ground IMHO is
> that of not inserting a decl for the unmangled name, but treat this
> symbol always as-it-is.
> i.e. if we have a symbol _Znwm in some object, we don't insert a decl
> for `operator new(unsigned long)` but for _Znwm itself.
> 
> Greg, Jason, would that work for you guys?

I would be ok with that.

> 
> Thanks!
> 
> --
> Davide
> 
> On Tue, Mar 13, 2018 at 10:25 AM, Davide Italiano  
> wrote:
>> On Tue, Mar 13, 2018 at 9:59 AM, Frédéric Riss via lldb-commits
>>  wrote:
>>> 
>>> 
 On Mar 12, 2018, at 6:40 PM, Davide Italiano via lldb-commits 
  wrote:
 
 Author: davide
 Date: Mon Mar 12 18:40:00 2018
 New Revision: 327356
 
 URL: http://llvm.org/viewvc/llvm-project?rev=327356=rev
 Log:
 [ExpressionParser] Fix crash when evaluating invalid expresssions.
 
 Typical example, illformed comparisons (operator== where LHS and
 RHS are not compatible). If a symbol matched `operator==` in any
 of the object files lldb inserted a generic function declaration
 in the ASTContext on which Sema operates. Maintaining the AST
 context invariants is fairly tricky and sometimes resulted in
 crashes inside clang (or assertions hit).
 
 The real reason why this feature exists in the first place is
 that of allowing users to do something like:
 (lldb) call printf("patatino")
 
 even if the debug informations for printf() is not available.
 Eventually, we might reconsider this feature in its
 entirety, but for now we can't remove it as it would break
 a bunch of users. Instead, try to limit it to non-C++ symbols,
 where getting the invariants right is hopefully easier.
 
 Now you can't do in lldb anymore
 (lldb) call _Zsomethingsomething(1,2,3)
 
 but that doesn't seem to be such a big loss.
>>> 
>>> I’m somewhat surprised by this. My understanding of the crash you were 
>>> investigating is that Clang crashed because we injected a Decl looking like 
>>> this: “void operator==(…)” after finding the operator== symbol somewhere. I 
>>> think injecting bogus C++ Decls makes no sense and it cannot really work 
>>> anyway.
>>> 
>>> On the other hand, I see no harm in injecting “_Zsomethingsomething(…)” as 
>>> a C Decl. This can be useful, and people should be able to call raw symbols 
>>> in their binaries. Is there no way to keep the later while preventing the 
>>> creation of broken C++ decls?
>>> 
>> 
>> Thank you all for your feedback. I'll reply with a single mail to everybody.
>> 
>> C decls can be inserted. In fact, this works, even after my changes:
>> 
>> (lldb) call printf("patatino")
>> (int) $0 = 8
>> 
>> I always thought identifiers beginning with underscore where illegal in C.
>> Here's what the standard says:
>> 
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
>> 
>> Section 7.1.3
>> "All identifiers that begin with an underscore and either an uppercase
>> letter or another underscore are always reserved for any use."
>> 
>> They're not quite illegal, but they're reserved, so I'm unsure how
>> frequent having symbols starting with `_Z` is popular.
>> 
>> Maybe lldb has a better way of detecting whether this is a C or a C++ 
>> program?
>> 
>> There are several constraints:
>> 
>> 1) The object from which we're loading symbols has no debug info, so
>> we can't look at the CU and just say whether it's C or C++ or
>> Objective-C.
>> 2) The expression parser always evaluates expressions in a C++ context
>> (to the best of my understanding)
>> 3) You can always mix-and-match C/C++ object files as they're just
>> Mach-O or ELF objects at that point (not recommended, but I've seen
>> people doing it).
>> 
>> Do you have any thoughts on how this should be achieved?
>> 
>> Best,
>> 
>> --
>> Davide
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Davide Italiano via lldb-commits 
On Tue, Mar 13, 2018 at 10:57 AM, Greg Clayton  wrote:
>
>
>> On Mar 13, 2018, at 10:37 AM, Davide Italiano via lldb-commits 
>>  wrote:
>>
>> An alternative proposed by Fred which is an OK middle ground IMHO is
>> that of not inserting a decl for the unmangled name, but treat this
>> symbol always as-it-is.
>> i.e. if we have a symbol _Znwm in some object, we don't insert a decl
>> for `operator new(unsigned long)` but for _Znwm itself.
>>
>> Greg, Jason, would that work for you guys?
>
> I would be ok with that.
>

I'm going to send a review for this soon.

Best,

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

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Greg Clayton via lldb-commits 
I agree with Jason, we shouldn't be looking at magic naming and making 
assumptions. What is the name is a C function that starts with _Z.

Both of Jason's examples below should work. Sometimes we only have symbol 
tables and if people are able to only get to the C++ function via a mangled 
name, they should be able to use it.

Greg


> On Mar 13, 2018, at 10:13 AM, Jason Molenda via lldb-commits 
>  wrote:
> 
> 
> 
>> On Mar 12, 2018, at 7:52 PM, Davide Italiano via lldb-commits 
>>  wrote:
>> 
>> On Mon, Mar 12, 2018 at 7:27 PM, Jason Molenda via lldb-commits
>>  wrote:
>>> FWIW, we'll definitely get pushback about
>>> 
 Now you can't do in lldb anymore
 (lldb) call _Zsomethingsomething(1,2,3)
>>> 
>>> 
>>> There are clever users of lldb, often working at assembly language level 
>>> without any symbolic information, who are able to correctly call a C++ 
>>> mangled function by hand.  It's not something I'd want to do personally, 
>>> but I'd be mad at my debugger if it gave me an error message when I told it 
>>> what to do.
>>> 
>>> 
>> 
>> I understand your point. We had several discussions about this and I
>> was really reluctant to push this change to begin with.
> 
> Sorry for missing out on the earlier discussions and coming in to this late.
> 
> 
> I don't understand exactly what's going on here.  If I have a program like
> 
> extern "C"  void takefive_c(int five) {};
> void takefive_cpp(int five) {}
> int main () {}
> 
> compiled without debug information, I can do
> 
> (lldb) p (void)takefive_c(5)
> (lldb) p (void)_Z12takefive_cppi(5)
> 
> 
> why is the second expression any different than the first?  I'm calling a 
> symbol name without any debug information, prototypes, or types at all.
> 
> 
> 
> 
>> I thought about alternatives and basically I ended up realizing that
>> maintaining the invariants that the AST wants Is crazytown.
>> You don't need to squint too hard to see that basically nobody using
>> clang does this.
>> All the clang tools prefer to insert text in a source file and reparse
>> it because modifying the AST in place is hard.
>> It's funny that they do that because the changes they make are
>> generally fairly localized, but nobody really understands what Sema
>> really wants (note, the invariants are hardcoded in the Sema path).
>> Injecting a generic decl in the context and crossing finger is not
>> really great IMHO. It causes crashes, which, from what I understand in
>> the lldb world are much worse than not being able to display
>> informations (from what I can see the mantra of lldb is "the debugger
>> should never crash").
>> 
>> So, yes, this patch is in some way picking one of two poisons. If we
>> want to take a look at this again (i.e. we consider it important
>> enough), then the interaction between debugger and compiler needs to
>> be rethought to inject something less terrible than a generic decl.
>> This is, needless to say, fairly hard because in this case you're
>> getting the symbols from a Mach-O object file, so all the state you
>> have is a mangled symbol name, which doesn't contain enough
>> information to reconstruct the whole context. In swift we can do
>> better because we have a fully-fledged type reconstruction mechanism
>> (swift::ide::GetTypeFromMangledSymbolName()), and even there, we
>> experienced a fair amount of pain because the path still has issues
>> that need to be shaken.
>> 
>> tl;dr if somebody wants to rewrite this, I'll be very happy to support
>> this , but I don't see a real reason to keep the feature in an
>> half-baked state.
>> 
>> Best,
>> 
>> --
>> Davide
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits 
> 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Davide Italiano via lldb-commits 
On Tue, Mar 13, 2018 at 9:59 AM, Frédéric Riss via lldb-commits
 wrote:
>
>
>> On Mar 12, 2018, at 6:40 PM, Davide Italiano via lldb-commits 
>>  wrote:
>>
>> Author: davide
>> Date: Mon Mar 12 18:40:00 2018
>> New Revision: 327356
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=327356=rev
>> Log:
>> [ExpressionParser] Fix crash when evaluating invalid expresssions.
>>
>> Typical example, illformed comparisons (operator== where LHS and
>> RHS are not compatible). If a symbol matched `operator==` in any
>> of the object files lldb inserted a generic function declaration
>> in the ASTContext on which Sema operates. Maintaining the AST
>> context invariants is fairly tricky and sometimes resulted in
>> crashes inside clang (or assertions hit).
>>
>> The real reason why this feature exists in the first place is
>> that of allowing users to do something like:
>> (lldb) call printf("patatino")
>>
>> even if the debug informations for printf() is not available.
>> Eventually, we might reconsider this feature in its
>> entirety, but for now we can't remove it as it would break
>> a bunch of users. Instead, try to limit it to non-C++ symbols,
>> where getting the invariants right is hopefully easier.
>>
>> Now you can't do in lldb anymore
>> (lldb) call _Zsomethingsomething(1,2,3)
>>
>> but that doesn't seem to be such a big loss.
>
> I’m somewhat surprised by this. My understanding of the crash you were 
> investigating is that Clang crashed because we injected a Decl looking like 
> this: “void operator==(…)” after finding the operator== symbol somewhere. I 
> think injecting bogus C++ Decls makes no sense and it cannot really work 
> anyway.
>
> On the other hand, I see no harm in injecting “_Zsomethingsomething(…)” as a 
> C Decl. This can be useful, and people should be able to call raw symbols in 
> their binaries. Is there no way to keep the later while preventing the 
> creation of broken C++ decls?
>

Thank you all for your feedback. I'll reply with a single mail to everybody.

C decls can be inserted. In fact, this works, even after my changes:

(lldb) call printf("patatino")
(int) $0 = 8

I always thought identifiers beginning with underscore where illegal in C.
Here's what the standard says:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Section 7.1.3
"All identifiers that begin with an underscore and either an uppercase
letter or another underscore are always reserved for any use."

They're not quite illegal, but they're reserved, so I'm unsure how
frequent having symbols starting with `_Z` is popular.

Maybe lldb has a better way of detecting whether this is a C or a C++ program?

There are several constraints:

1) The object from which we're loading symbols has no debug info, so
we can't look at the CU and just say whether it's C or C++ or
Objective-C.
2) The expression parser always evaluates expressions in a C++ context
(to the best of my understanding)
3) You can always mix-and-match C/C++ object files as they're just
Mach-O or ELF objects at that point (not recommended, but I've seen
people doing it).

Do you have any thoughts on how this should be achieved?

Best,

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

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Greg Clayton via lldb-commits 


> On Mar 13, 2018, at 10:25 AM, Davide Italiano via lldb-commits 
>  wrote:
> 
> On Tue, Mar 13, 2018 at 9:59 AM, Frédéric Riss via lldb-commits
> > wrote:
>> 
>> 
>>> On Mar 12, 2018, at 6:40 PM, Davide Italiano via lldb-commits 
>>>  wrote:
>>> 
>>> Author: davide
>>> Date: Mon Mar 12 18:40:00 2018
>>> New Revision: 327356
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=327356=rev
>>> Log:
>>> [ExpressionParser] Fix crash when evaluating invalid expresssions.
>>> 
>>> Typical example, illformed comparisons (operator== where LHS and
>>> RHS are not compatible). If a symbol matched `operator==` in any
>>> of the object files lldb inserted a generic function declaration
>>> in the ASTContext on which Sema operates. Maintaining the AST
>>> context invariants is fairly tricky and sometimes resulted in
>>> crashes inside clang (or assertions hit).
>>> 
>>> The real reason why this feature exists in the first place is
>>> that of allowing users to do something like:
>>> (lldb) call printf("patatino")
>>> 
>>> even if the debug informations for printf() is not available.
>>> Eventually, we might reconsider this feature in its
>>> entirety, but for now we can't remove it as it would break
>>> a bunch of users. Instead, try to limit it to non-C++ symbols,
>>> where getting the invariants right is hopefully easier.
>>> 
>>> Now you can't do in lldb anymore
>>> (lldb) call _Zsomethingsomething(1,2,3)
>>> 
>>> but that doesn't seem to be such a big loss.
>> 
>> I’m somewhat surprised by this. My understanding of the crash you were 
>> investigating is that Clang crashed because we injected a Decl looking like 
>> this: “void operator==(…)” after finding the operator== symbol somewhere. I 
>> think injecting bogus C++ Decls makes no sense and it cannot really work 
>> anyway.
>> 
>> On the other hand, I see no harm in injecting “_Zsomethingsomething(…)” as a 
>> C Decl. This can be useful, and people should be able to call raw symbols in 
>> their binaries. Is there no way to keep the later while preventing the 
>> creation of broken C++ decls?
>> 
> 
> Thank you all for your feedback. I'll reply with a single mail to everybody.
> 
> C decls can be inserted. In fact, this works, even after my changes:
> 
> (lldb) call printf("patatino")
> (int) $0 = 8

That is because we define a function prototype for printf. So please try 
another function. You always have to cast the result of a function call to a 
symbol. In this case, since you didn't get a warning, you can know that you 
didn't use a symbol...

> 
> I always thought identifiers beginning with underscore where illegal in C.
> Here's what the standard says:
> 
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf 
> 
> 
> Section 7.1.3
> "All identifiers that begin with an underscore and either an uppercase
> letter or another underscore are always reserved for any use."

And yet there are many symbols that violate this. Just because someone says it 
is so, doesn't mean it is and also if there is no enforcement, then the rule 
doesn't mean much.

> 
> They're not quite illegal, but they're reserved, so I'm unsure how
> frequent having symbols starting with `_Z` is popular.

It is a legal C identifier, so we need to be able to call it.

> 
> Maybe lldb has a better way of detecting whether this is a C or a C++ program?

Yes with debug info, no if we only have symbol table.

> 
> There are several constraints:
> 
> 1) The object from which we're loading symbols has no debug info, so
> we can't look at the CU and just say whether it's C or C++ or
> Objective-C.
> 2) The expression parser always evaluates expressions in a C++ context
> (to the best of my understanding)
> 3) You can always mix-and-match C/C++ object files as they're just
> Mach-O or ELF objects at that point (not recommended, but I've seen
> people doing it).
> 
> Do you have any thoughts on how this should be achieved?

What are you trying to achieve?

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

[Lldb-commits] [PATCH] D44456: [SymbolFilePDB] Simplify getting the source file path

2018-03-13 Thread Aaron Smith via Phabricator via lldb-commits 
asmith created this revision.
asmith added reviewers: zturner, rnk, lldb-commits.
Herald added a subscriber: llvm-commits.

Replace SymbolFilePDB::GetSourceFileNameForPDBCompiland() with 
PDBSymbolCompiland::getSourceFileFullPath().


Repository:
  rL LLVM

https://reviews.llvm.org/D44456

Files:
  source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
  source/Plugins/SymbolFile/PDB/SymbolFilePDB.h

Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
@@ -198,9 +198,6 @@
   void GetCompileUnitIndex(const llvm::pdb::PDBSymbolCompiland *pdb_compiland,
uint32_t );
 
-  std::string GetSourceFileNameForPDBCompiland(
-  const llvm::pdb::PDBSymbolCompiland *pdb_compiland);
-
   std::unique_ptr
   GetPDBCompilandByUID(uint32_t uid);
 
Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
@@ -589,59 +589,6 @@
   return resolved_flags;
 }
 
-std::string SymbolFilePDB::GetSourceFileNameForPDBCompiland(
-const PDBSymbolCompiland *pdb_compiland) {
-  if (!pdb_compiland)
-return std::string();
-
-  std::string source_file_name;
-  // `getSourceFileName` returns the basename of the original source file
-  // used to generate this compiland.  It does not return the full path.
-  // Currently the only way to get that is to do a basename lookup to get the
-  // IPDBSourceFile, but this is ambiguous in the case of two source files
-  // with the same name contributing to the same compiland. This is an edge
-  // case that we ignore for now, although we need to a long-term solution.
-  std::string file_name = pdb_compiland->getSourceFileName();
-  if (!file_name.empty()) {
-auto one_src_file_up =
-m_session_up->findOneSourceFile(pdb_compiland, file_name,
-PDB_NameSearchFlags::NS_CaseInsensitive);
-if (one_src_file_up)
-  source_file_name = one_src_file_up->getFileName();
-  }
-  // For some reason, source file name could be empty, so we will walk through
-  // all source files of this compiland, and determine the right source file
-  // if any that is used to generate this compiland based on language
-  // indicated in compilanddetails language field.
-  if (!source_file_name.empty())
-return source_file_name;
-
-  auto details_up = pdb_compiland->findOneChild();
-  PDB_Lang pdb_lang = details_up ? details_up->getLanguage() : PDB_Lang::Cpp;
-  auto src_files_up =
-  m_session_up->getSourceFilesForCompiland(*pdb_compiland);
-  if (src_files_up) {
-while (auto file_up = src_files_up->getNext()) {
-  FileSpec file_spec(file_up->getFileName(), false,
- FileSpec::ePathSyntaxWindows);
-  auto file_extension = file_spec.GetFileNameExtension();
-  if (pdb_lang == PDB_Lang::Cpp || pdb_lang == PDB_Lang::C) {
-static const char* exts[] = { "cpp", "c", "cc", "cxx" };
-if (llvm::is_contained(exts, file_extension.GetStringRef().lower())) {
-  source_file_name = file_up->getFileName();
-  break;
-}
-  } else if (pdb_lang == PDB_Lang::Masm &&
- ConstString::Compare(file_extension, ConstString("ASM"),
-  false) == 0) {
-source_file_name = file_up->getFileName();
-break;
-  }
-}
-  }
-  return source_file_name;
-}
-
 uint32_t SymbolFilePDB::ResolveSymbolContext(
 const lldb_private::FileSpec _spec, uint32_t line, bool check_inlines,
 uint32_t resolve_scope, lldb_private::SymbolContextList _list) {
@@ -665,15 +612,7 @@
   // For inline functions, we don't have to match the FileSpec since they
   // could be defined in headers other than file specified in FileSpec.
   if (!check_inlines) {
-// `getSourceFileName` returns the basename of the original source file
-// used to generate this compiland.  It does not return the full path.
-// Currently the only way to get that is to do a basename lookup to get
-// the IPDBSourceFile, but this is ambiguous in the case of two source
-// files with the same name contributing to the same compiland.  This is
-// a moderately extreme edge case, so we consider this OK for now,
-// although we need to find a long-term solution.
-std::string source_file =
-GetSourceFileNameForPDBCompiland(compiland.get());
+std::string source_file = compiland->getSourceFileFullPath();
 if (source_file.empty())
   continue;
 FileSpec this_spec(source_file, false, FileSpec::ePathSyntaxWindows);
@@ -1262,7 +1201,7 @@
   if (lang == lldb::LanguageType::eLanguageTypeUnknown)
 return CompUnitSP();
 
-

[Lldb-commits] [PATCH] D44455: [SymbolFilePDB] Remove a few null pointer checks by passing ref

2018-03-13 Thread Aaron Smith via Phabricator via lldb-commits 
asmith created this revision.
asmith added reviewers: zturner, rnk, lldb-commits.
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D44455

Files:
  source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
  source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
  source/Plugins/SymbolFile/PDB/SymbolFilePDB.h

Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
@@ -188,14 +188,14 @@
   typedef std::vector TypeCollection;
 
   void
-  GetTypesForPDBSymbol(const llvm::pdb::PDBSymbol *pdb_symbol,
+  GetTypesForPDBSymbol(const llvm::pdb::PDBSymbol _symbol,
uint32_t type_mask, TypeCollection _collection);
 
   lldb_private::Function* ParseCompileUnitFunctionForPDBFunc(
-  const llvm::pdb::PDBSymbolFunc *pdb_func,
+  const llvm::pdb::PDBSymbolFunc _func,
   const lldb_private::SymbolContext );
 
-  void GetCompileUnitIndex(const llvm::pdb::PDBSymbolCompiland *pdb_compiland,
+  void GetCompileUnitIndex(const llvm::pdb::PDBSymbolCompiland _compiland,
uint32_t );
 
   std::string GetSourceFileNameForPDBCompiland(
@@ -205,9 +205,9 @@
   GetPDBCompilandByUID(uint32_t uid);
 
   lldb_private::Mangled
-  GetMangledForPDBFunc(const llvm::pdb::PDBSymbolFunc *pdb_func);
+  GetMangledForPDBFunc(const llvm::pdb::PDBSymbolFunc _func);
 
-  bool ResolveFunction(llvm::pdb::PDBSymbolFunc *pdb_func,
+  bool ResolveFunction(const llvm::pdb::PDBSymbolFunc _func,
bool include_inlines,
lldb_private::SymbolContextList _list);
 
Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
@@ -205,15 +205,12 @@
 }
 
 void SymbolFilePDB::GetCompileUnitIndex(
-const llvm::pdb::PDBSymbolCompiland *pdb_compiland,
+const llvm::pdb::PDBSymbolCompiland _compiland,
 uint32_t ) {
-  if (!pdb_compiland)
-return;
-
   auto results_up = m_global_scope_up->findAllChildren();
   if (!results_up)
 return;
-  auto uid = pdb_compiland->getSymIndexId();
+  auto uid = pdb_compiland.getSymIndexId();
   for (uint32_t cu_idx = 0; cu_idx < GetNumCompileUnits(); ++cu_idx) {
 auto compiland_up = results_up->getChildAtIndex(cu_idx);
 if (!compiland_up)
@@ -266,32 +263,31 @@
 
 lldb_private::Function *
 SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc(
-const PDBSymbolFunc *pdb_func,
+const PDBSymbolFunc _func,
 const lldb_private::SymbolContext ) {
-  assert(pdb_func != nullptr);
   lldbassert(sc.comp_unit && sc.module_sp.get());
 
-  auto file_vm_addr = pdb_func->getVirtualAddress();
+  auto file_vm_addr = pdb_func.getVirtualAddress();
   if (file_vm_addr == LLDB_INVALID_ADDRESS)
 return nullptr;
 
-  auto func_length = pdb_func->getLength();
+  auto func_length = pdb_func.getLength();
   AddressRange func_range = AddressRange(file_vm_addr,
  func_length,
  sc.module_sp->GetSectionList());
   if (!func_range.GetBaseAddress().IsValid())
 return nullptr;
 
-  lldb_private::Type* func_type = ResolveTypeUID(pdb_func->getSymIndexId());
+  lldb_private::Type* func_type = ResolveTypeUID(pdb_func.getSymIndexId());
   if (!func_type)
 return nullptr;
 
-  user_id_t func_type_uid = pdb_func->getSignatureId();
+  user_id_t func_type_uid = pdb_func.getSignatureId();
 
   Mangled mangled = GetMangledForPDBFunc(pdb_func);
 
   FunctionSP func_sp = std::make_shared(sc.comp_unit,
-  pdb_func->getSymIndexId(),
+  pdb_func.getSymIndexId(),
   func_type_uid,
   mangled,
   func_type,
@@ -315,7 +311,7 @@
 auto func_sp =
 sc.comp_unit->FindFunctionByUID(pdb_func_up->getSymIndexId());
 if (!func_sp) {
-  if (ParseCompileUnitFunctionForPDBFunc(pdb_func_up.get(), sc))
+  if (ParseCompileUnitFunctionForPDBFunc(*pdb_func_up, sc))
 ++func_added;
 }
   }
@@ -562,7 +558,7 @@
 auto func_uid = pdb_func->getSymIndexId();
 sc.function = sc.comp_unit->FindFunctionByUID(func_uid).get();
 if (sc.function == nullptr)
-  sc.function = ParseCompileUnitFunctionForPDBFunc(pdb_func, sc);
+  sc.function = ParseCompileUnitFunctionForPDBFunc(*pdb_func, sc);
 if (sc.function) {
   resolved_flags |= eSymbolContextFunction;
   if (resolve_scope & eSymbolContextBlock) {
@@ -736,7 +732,7 @@
   if (sc.function == nullptr) {
 auto

[Lldb-commits] [PATCH] D44456: [SymbolFilePDB] Simplify getting the source file path

2018-03-13 Thread Aaron Smith via Phabricator via lldb-commits 
asmith added a comment.

Has a dependence on https://reviews.llvm.org/D44458


Repository:
  rL LLVM

https://reviews.llvm.org/D44456



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

Re: [Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

2018-03-13 Thread Davide Italiano via lldb-commits 
On Tue, Mar 13, 2018 at 2:43 PM, Jason Molenda  wrote:
>
>
>> On Mar 13, 2018, at 11:51 AM, Davide Italiano via lldb-commits 
>>  wrote:
>>
>> We had the report of a crash where lldb was setting a conditional
>> breakpoint on an invalid condition (CGRect == pointer, which is,
>> ill-formed).
>> The symbol-based resolution of lldb was picking a random operator==,
>> inserting a generic function decl operator== in the context because it
>> happened to find a matching symbol somewhere in the system.
>>
>> clang expects operator== to have at least one argument, so you end up
>> hitting this assertion in Sema.
>>
>> (lldb) Assertion failed: (i < getNumParams() && "Illegal param #"),
>> function getParamDecl, file
>> /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/clang/include/clang/AST/Decl.h,
>> line 2232.
>>
>> So, to answer your question, Greg, I just want lldb to not inject
>> arbitrary C++ func decl. What do you think is the best way of
>> achieving this?
>>
>
>
> I put together a repo case that might help make this clearer (attached)
>
>
>
>
>
> we have a test program with three translation units.  One has C++ methods and 
> was built with debug info ("foo"), one has C++ methods and was built without 
> debug info ("bar").  It tries calling these from lldb:
>
>
> (lldb) p (void)foo('c')
> in foo(char)
> (lldb) p (void)foo(5)
> in foo(int)
> (lldb) p (void)foo(5, 5)
> in foo(int, int)
>
> We had debug info for foo(), called the correct methods.
>
>
> (lldb) p (void)bar('c')
> in bar(char *)
> (lldb) p (void)bar(5)
> in bar(char *)
> (lldb) p (void)bar(5, 5)
> in bar(char *)
>
>
> Here, we have no debug info for bar(), so we grabbed the first bar() method 
> we found and used it for all calls.  This is a problem.
>
>
> (lldb) p (void)_Z3barc('c')
> in bar(char)
> (lldb) p (void)_Z3bari(5)
> in bar(int)
> (lldb) p (void)_Z3barii(5,5)
> in bar(int, int)
>
> Calling the mangled name bar()'s directly works as expected.
>
>
>
> Davide is trying to solve that middle one.  I think the problem he was 
> working on is where we had an expression using operator== and the first 
> "decl" we found of this was in a no-debug-info translation unit, and that 
> randomly chosen operator== was used when there WAS debug info for this 
> operator== in a different translation unit in the process.
>
> The question I have is -- should this even be allowed.  Should you be able to 
> call a C++ method using a demangled name with no debug info?  I'm trying to 
> think of a case where people do this today.  Clearly it does not work 
> correctly today for overloaded functions.  And apparently this could be 
> chosen over a debug info definition that might appear elsewhere in the 
> process?  I didn't try to test that.
>

The debug info version, if present has precedence. The scary bit is
that if you have several symbols matching the decl name (e.g.
`operator==`) lldb will pick a random one [the last one in the list it
builds according to some order]. I don't think this is the expected
behavior, but this is what we have today.

Thanks,

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

[Lldb-commits] [PATCH] D44321: Support demangling for D symbols via dlopen

2018-03-13 Thread Timothee Cour via Phabricator via lldb-commits 
timotheecour added a comment.

> Actually, this is not the correct interface is it? The returned pointer 
> should point to newly allocated memory using malloc, right?
>  Good to document that somewhere.

not 100% sure what you mean in that comment but I just pushed a commit that 
clarifies that point: 'The returned pointer should be allocated via malloc and 
owned by the caller' ; the reference implementation of liblldbplugin does the 
right thing.


https://reviews.llvm.org/D44321



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

[Lldb-commits] [PATCH] D44321: Support demangling for D symbols via dlopen

2018-03-13 Thread Timothee Cour via Phabricator via lldb-commits 
timotheecour updated this revision to Diff 138291.
timotheecour added a comment.

- document C interface


https://reviews.llvm.org/D44321

Files:
  include/lldb/Core/Mangled.h
  include/lldb/Core/PluginManager.h
  source/API/SystemInitializerFull.cpp
  source/Core/CMakeLists.txt
  source/Core/Mangled.cpp
  source/Core/PluginManager.cpp
  source/Plugins/Language/CMakeLists.txt
  source/Plugins/Language/D/CMakeLists.txt
  source/Plugins/Language/D/DLanguage.cpp
  source/Plugins/Language/D/DLanguage.h

Index: source/Plugins/Language/D/DLanguage.h
===
--- /dev/null
+++ source/Plugins/Language/D/DLanguage.h
@@ -0,0 +1,81 @@
+//===-- DLanguage.h -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+/*
+to use, add this to .lldbinit:
+settings set plugin.language.D.pluginfile "path/to/liblldbdplugin.dylib"
+example of such plugin:
+https://github.com/timotheecour/dtools/blob/master/dtools/lldbdplugin.d
+*/
+
+#ifndef liblldb_DLanguage_h_
+#define liblldb_DLanguage_h_
+
+// C Includes
+// C++ Includes
+// Other libraries and framework includes
+// Project includes
+#include "lldb/Target/Language.h"
+#include "lldb/lldb-private.h"
+
+namespace lldb_private {
+
+class DLanguageProperties : public Properties {
+public:
+  DLanguageProperties();
+
+  ~DLanguageProperties() override;
+
+  llvm::StringRef GetPluginfileDlang();
+};
+
+class DLanguage : public Language {
+public:
+  typedef std::shared_ptr DLanguagePropertiesSP;
+
+  DLanguage() = default;
+
+  ~DLanguage() override = default;
+
+  lldb::LanguageType GetLanguageType() const override {
+return lldb::eLanguageTypeD;
+  }
+
+  //--
+  // Static Functions
+  //--
+  static void Initialize();
+
+  static void Terminate();
+
+  static lldb_private::Language *CreateInstance(lldb::LanguageType language);
+
+  static void DebuggerInitialize(lldb_private::Debugger );
+
+  static DLanguage *Instance();
+
+  static const DLanguagePropertiesSP ();
+
+  static lldb_private::ConstString GetPluginNameStatic();
+
+  static bool IsDMangledName(const char *name);
+  // Consider using non-static methods
+  static char *demangle(const ConstString );
+
+  //--
+  // PluginInterface protocol
+  //--
+  ConstString GetPluginName() override;
+
+  uint32_t GetPluginVersion() override;
+};
+
+} // namespace lldb_private
+
+#endif // liblldb_DLanguage_h_
Index: source/Plugins/Language/D/DLanguage.cpp
===
--- /dev/null
+++ source/Plugins/Language/D/DLanguage.cpp
@@ -0,0 +1,153 @@
+//===-- DLanguage.cpp ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "DLanguage.h"
+
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Interpreter/OptionValueProperties.h"
+#include "lldb/Interpreter/OptionValueString.h"
+#include "lldb/Interpreter/Property.h"
+#include "lldb/Utility/ConstString.h"
+#include "lldb/Utility/Log.h"
+#include "llvm/Support/DynamicLibrary.h"
+
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+
+using llvm::sys::DynamicLibrary;
+
+namespace {
+
+template 
+Fun *getTypedSymbol(DynamicLibrary , const char *symbol) {
+  return reinterpret_cast(lib.getAddressOfSymbol(symbol));
+}
+
+// D Plugin will define these symbols. They're declared to use with decltype.
+extern "C" {
+// called once, to initialize druntime.
+void d_initialize();
+// The returned pointer should be allocated via malloc and owned by the caller.
+char *lldbd_demangle(size_t length, const char *mangled);
+}
+
+static PropertyDefinition g_properties[] = {
+{"pluginfile", OptionValue::eTypeString, true,
+ OptionValueString::eOptionEncodeCharacterEscapeSequences, "", nullptr,
+ "The plugin shared library file to use for D language."},
+};
+
+enum {
+  ePropertyPluginfileDlang,
+};
+
+} // anonymous namespace
+
+// DLanguageProperties
+DLanguageProperties::~DLanguageProperties() = default;
+
+DLanguageProperties::DLanguageProperties() : Properties() {
+  m_collection_sp.reset(
+  new OptionValueProperties(DLanguage::GetPluginNameStatic()));
+  m_collection_sp->Initialize(g_properties);
+}
+
+// DLanguage
+llvm::StringRef