Re: [lldb-dev] Custom arguments completion for commands created by LLDB plugins

[Raphael “Teemperor” Isemann via lldb-dev]

To my knowledge there is no way to have completions for custom commands. If you 
just want completions for nested commands (e.g., having a “custom add” and 
“custom remove” commands and want completions for completing “add” and 
“remove”), then this should work if you build the nested command using the 
SBCommand::Add[Multiword]Command functions. However, that won’t allow you to 
provide arbitrary completions for arguments.

Regarding your planned change: Adding a new virtual method would break the ABI 
of SBCommandPluginInterface and the SBAPI is supposed to have a stable ABI. So 
I guess we have two options.
1. break the ABI for this class and somehow let people know they need to 
recompile their plugins for the next release.
2. add a new overload to the existing AddCommand methods and allow passing some 
kind of interface for completions. Custom command classes just inherit from 
both interfaces if they want to provide their own completions.

I’m fine with either option, but if we end up going for option 1, then IMHO we 
might as well change the API of this class as it’s current DoExecute function 
is just wrong. It returns an undocumented ‘bool’ value which seems to provide 
redundant information to the success status of the result parameter and we pass 
it a `char **` parameter which actually has `const char **` semantics as 
changing it corrupts LLDB’s internal `Args` data structure.

In any case I would prefer if we wait with landing this API until I fully 
cleaned up LLDB's completion logic and we got around to set in stone the new 
HandleCompletion API (which gives us an overview of what kind of completions 
clients want to receive and in what format). Both should happen for LLDB 10 if 
everything goes right, so this shouldn’t delay adding this feature.

- Raphael

(Resending this as my other email got blocked by lldb-dev somehow)

> On 6. Oct 2019, at 02:55, Matheus Marchini via lldb-dev 
>  wrote:
> 
> Is there a way to create custom argument completion handlers for
> commands introduced by LLDB plugins? I want to add completion for some
> commands on llnode (https://github.com/nodejs/llnode), but I couldn't
> find a way to do so using the C++ public API.
> 
> Based on this comment
> (https://github.com/llvm/llvm-project/blob/d420616313a3b4bc95a9effa00363cf3ad953e61/lldb/include/lldb/Interpreter/CommandCompletions.h#L44-L47)
> I was expecting some API to add custom completion handlers, but I
> guess the comment is intended for internal development only?
> 
> If there isn't a way to do that today, I'm thinking about adding it as
> a new method to SBCommandPluginInterface, unless someone objects to
> it.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


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

[lldb-dev] [Bug 43588] New: argv[0] is always passed as absolute

[via lldb-dev]

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

Bug ID: 43588
   Summary: argv[0] is always passed as absolute
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: jan.kratoch...@redhat.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

echo 'int main(int argc,char **argv){}'|clang -g -x c
-;~/redhat/llvm-monorepo-clangassert/bin/lldb -batch ./a.out -o 'b main' -o r
-o 'p argv[0]'

Actual:
(char *) $0 = "/tmp/a.out"

Expected:
(char *) $0 = "./a.out"

Some debuggee issues being debugged may depend on its argv[0].

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

Re: [lldb-dev] Custom arguments completion for commands created by LLDB plugins

[Jim Ingham via lldb-dev]

> On Oct 7, 2019, at 3:35 AM, Raphael “Teemperor” Isemann via lldb-dev 
>  wrote:
> 
> To my knowledge there is no way to have completions for custom commands. If 
> you just want completions for nested commands (e.g., having a “custom add” 
> and “custom remove” commands and want completions for completing “add” and 
> “remove”), then this should work if you build the nested command using the 
> SBCommand::Add[Multiword]Command functions. However, that won’t allow you to 
> provide arbitrary completions for arguments.
> 
> Regarding your planned change: Adding a new virtual method would break the 
> ABI of SBCommandPluginInterface and the SBAPI is supposed to have a stable 
> ABI. So I guess we have two options.
> 1. break the ABI for this class and somehow let people know they need to 
> recompile their plugins for the next release.
> 2. add a new overload to the existing AddCommand methods and allow passing 
> some kind of interface for completions. Custom command classes just inherit 
> from both interfaces if they want to provide their own completions.

I don't think that's the right way to handle completions for custom commands.  
Custom commands already suffer from the fact that they have to parse their own 
arguments and options, so they don't work like lldb commands.  We can't do 
their help correctly because we don't know this info, and if they used any of 
the common completion types, they would have to reimplement them.

Instead of adding another ad hoc behavior that the builtin lldb commands don't 
use, we should really allow custom commands to be regular LLDB commands, by 
having some API the command can call when added to set up its arguments and 
options.  The these could get built in the command table just like the built-in 
lldb commands, and lldb could handle the help and completions.  For all the 
known completion types, you could then just say "This is a file" or "This is a 
symbol" etc. and lldb would handle the completion.  And if you have a custom 
completion callback for some argument, you would just provide a function 
pointer to the "AddOption" or "AddArgument" API's.

Jim



> I’m fine with either option, but if we end up going for option 1, then IMHO 
> we might as well change the API of this class as it’s current DoExecute 
> function is just wrong. It returns an undocumented ‘bool’ value which seems 
> to provide redundant information to the success status of the result 
> parameter and we pass it a `char **` parameter which actually has `const char 
> **` semantics as changing it corrupts LLDB’s internal `Args` data structure.
> 
> In any case I would prefer if we wait with landing this API until I fully 
> cleaned up LLDB's completion logic and we got around to set in stone the new 
> HandleCompletion API (which gives us an overview of what kind of completions 
> clients want to receive and in what format). Both should happen for LLDB 10 
> if everything goes right, so this shouldn’t delay adding this feature.
> 
> - Raphael
> 
> (Resending this as my other email got blocked by lldb-dev somehow)
> 
>> On 6. Oct 2019, at 02:55, Matheus Marchini via lldb-dev 
>>  wrote:
>> 
>> Is there a way to create custom argument completion handlers for
>> commands introduced by LLDB plugins? I want to add completion for some
>> commands on llnode (https://github.com/nodejs/llnode), but I couldn't
>> find a way to do so using the C++ public API.
>> 
>> Based on this comment
>> (https://github.com/llvm/llvm-project/blob/d420616313a3b4bc95a9effa00363cf3ad953e61/lldb/include/lldb/Interpreter/CommandCompletions.h#L44-L47)
>> I was expecting some API to add custom completion handlers, but I
>> guess the comment is intended for internal development only?
>> 
>> If there isn't a way to do that today, I'm thinking about adding it as
>> a new method to SBCommandPluginInterface, unless someone objects to
>> it.
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] Custom arguments completion for commands created by LLDB plugins

[Matheus Marchini via lldb-dev]

Nested command completion works. I want to complete parameters of
commands based on information from the debugged process (attributes of
an object, etc.).

> 1. break the ABI for this class and somehow let people know they need to 
> recompile their plugins for the next release.

I'd rather not break ABI just for this change.

> 2. add a new overload to the existing AddCommand methods and allow passing 
> some kind of interface for completions. Custom command classes just inherit 
> from both interfaces if they want to provide their own completions.

I like this idea. Multiple commands with same parameter types could
reuse the same completion class . We would need to overload AddCommand
on SBCommandInterpreter and SBCommand.

There are two other options similar to option two:

1. Add a new method to SBCommand to attach a completion class to it
(AddCompletion, for example).
2. Overload the constructor of SBCommandPluginInterface to receive a
pointer to a completion class instance, and save it as a private
member.

> In any case I would prefer if we wait with landing this API until I fully 
> cleaned up LLDB's completion logic and we got around to set in stone the new 
> HandleCompletion API (which gives us an overview of what kind of completions 
> clients want to receive and in what format). Both should happen for LLDB 10 
> if everything goes right, so this shouldn’t delay adding this feature.

I'm fine with waiting. I already have a POC adding a method to
SBCommandInterpreter, shouldn't be hard to change it to one of the
other options. If you don't mind, I can also send a patch with
whichever option we choose, the changes are non-intrusive and they
probably wouldn't get in the way of refactoring LLDB's completion
logic (if they do get in the way we can hold on landing it until
refactor is complete).

On Mon, Oct 7, 2019 at 3:35 AM Raphael “Teemperor” Isemann
 wrote:
>
> To my knowledge there is no way to have completions for custom commands. If 
> you just want completions for nested commands (e.g., having a “custom add” 
> and “custom remove” commands and want completions for completing “add” and 
> “remove”), then this should work if you build the nested command using the 
> SBCommand::Add[Multiword]Command functions. However, that won’t allow you to 
> provide arbitrary completions for arguments.
>
> Regarding your planned change: Adding a new virtual method would break the 
> ABI of SBCommandPluginInterface and the SBAPI is supposed to have a stable 
> ABI. So I guess we have two options.
> 1. break the ABI for this class and somehow let people know they need to 
> recompile their plugins for the next release.
> 2. add a new overload to the existing AddCommand methods and allow passing 
> some kind of interface for completions. Custom command classes just inherit 
> from both interfaces if they want to provide their own completions.
>
> I’m fine with either option, but if we end up going for option 1, then IMHO 
> we might as well change the API of this class as it’s current DoExecute 
> function is just wrong. It returns an undocumented ‘bool’ value which seems 
> to provide redundant information to the success status of the result 
> parameter and we pass it a `char **` parameter which actually has `const char 
> **` semantics as changing it corrupts LLDB’s internal `Args` data structure.
>
> In any case I would prefer if we wait with landing this API until I fully 
> cleaned up LLDB's completion logic and we got around to set in stone the new 
> HandleCompletion API (which gives us an overview of what kind of completions 
> clients want to receive and in what format). Both should happen for LLDB 10 
> if everything goes right, so this shouldn’t delay adding this feature.
>
> - Raphael
>
> (Resending this as my other email got blocked by lldb-dev somehow)
>
> > On 6. Oct 2019, at 02:55, Matheus Marchini via lldb-dev 
> >  wrote:
> >
> > Is there a way to create custom argument completion handlers for
> > commands introduced by LLDB plugins? I want to add completion for some
> > commands on llnode (https://github.com/nodejs/llnode), but I couldn't
> > find a way to do so using the C++ public API.
> >
> > Based on this comment
> > (https://github.com/llvm/llvm-project/blob/d420616313a3b4bc95a9effa00363cf3ad953e61/lldb/include/lldb/Interpreter/CommandCompletions.h#L44-L47)
> > I was expecting some API to add custom completion handlers, but I
> > guess the comment is intended for internal development only?
> >
> > If there isn't a way to do that today, I'm thinking about adding it as
> > a new method to SBCommandPluginInterface, unless someone objects to
> > it.
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Custom arguments completion for commands created by LLDB plugins

[Raphael “Teemperor” Isemann via lldb-dev]

Jim just ninja’d the discussion with his point that we could add methods for 
adding command completions to existing commands and I actually agree that’s the 
better idea (especially since this is abstracting away the actual option 
parsing from the user and it can be better integrated into the current option 
infrastructure in the future). Having said that, I think we should still take 
another look at the SBCommandPluginInterface and at least document how the user 
is supposed to implement that interface.

- Raphael

> On Oct 7, 2019, at 8:30 PM, Matheus Marchini  wrote:
> 
> Nested command completion works. I want to complete parameters of
> commands based on information from the debugged process (attributes of
> an object, etc.).
> 
>> 1. break the ABI for this class and somehow let people know they need to 
>> recompile their plugins for the next release.
> 
> I'd rather not break ABI just for this change.
> 
>> 2. add a new overload to the existing AddCommand methods and allow passing 
>> some kind of interface for completions. Custom command classes just inherit 
>> from both interfaces if they want to provide their own completions.
> 
> I like this idea. Multiple commands with same parameter types could
> reuse the same completion class . We would need to overload AddCommand
> on SBCommandInterpreter and SBCommand.
> 
> There are two other options similar to option two:
> 
> 1. Add a new method to SBCommand to attach a completion class to it
> (AddCompletion, for example).
> 2. Overload the constructor of SBCommandPluginInterface to receive a
> pointer to a completion class instance, and save it as a private
> member.
> 
>> In any case I would prefer if we wait with landing this API until I fully 
>> cleaned up LLDB's completion logic and we got around to set in stone the new 
>> HandleCompletion API (which gives us an overview of what kind of completions 
>> clients want to receive and in what format). Both should happen for LLDB 10 
>> if everything goes right, so this shouldn’t delay adding this feature.
> 
> I'm fine with waiting. I already have a POC adding a method to
> SBCommandInterpreter, shouldn't be hard to change it to one of the
> other options. If you don't mind, I can also send a patch with
> whichever option we choose, the changes are non-intrusive and they
> probably wouldn't get in the way of refactoring LLDB's completion
> logic (if they do get in the way we can hold on landing it until
> refactor is complete).
> 
> On Mon, Oct 7, 2019 at 3:35 AM Raphael “Teemperor” Isemann
>  wrote:
>> 
>> To my knowledge there is no way to have completions for custom commands. If 
>> you just want completions for nested commands (e.g., having a “custom add” 
>> and “custom remove” commands and want completions for completing “add” and 
>> “remove”), then this should work if you build the nested command using the 
>> SBCommand::Add[Multiword]Command functions. However, that won’t allow you to 
>> provide arbitrary completions for arguments.
>> 
>> Regarding your planned change: Adding a new virtual method would break the 
>> ABI of SBCommandPluginInterface and the SBAPI is supposed to have a stable 
>> ABI. So I guess we have two options.
>> 1. break the ABI for this class and somehow let people know they need to 
>> recompile their plugins for the next release.
>> 2. add a new overload to the existing AddCommand methods and allow passing 
>> some kind of interface for completions. Custom command classes just inherit 
>> from both interfaces if they want to provide their own completions.
>> 
>> I’m fine with either option, but if we end up going for option 1, then IMHO 
>> we might as well change the API of this class as it’s current DoExecute 
>> function is just wrong. It returns an undocumented ‘bool’ value which seems 
>> to provide redundant information to the success status of the result 
>> parameter and we pass it a `char **` parameter which actually has `const 
>> char **` semantics as changing it corrupts LLDB’s internal `Args` data 
>> structure.
>> 
>> In any case I would prefer if we wait with landing this API until I fully 
>> cleaned up LLDB's completion logic and we got around to set in stone the new 
>> HandleCompletion API (which gives us an overview of what kind of completions 
>> clients want to receive and in what format). Both should happen for LLDB 10 
>> if everything goes right, so this shouldn’t delay adding this feature.
>> 
>> - Raphael
>> 
>> (Resending this as my other email got blocked by lldb-dev somehow)
>> 
>>> On 6. Oct 2019, at 02:55, Matheus Marchini via lldb-dev 
>>>  wrote:
>>> 
>>> Is there a way to create custom argument completion handlers for
>>> commands introduced by LLDB plugins? I want to add completion for some
>>> commands on llnode (https://github.com/nodejs/llnode), but I couldn't
>>> find a way to do so using the C++ public API.
>>> 
>>> Based on this comment
>>> (https://github.com/llvm/llvm-project/blob/d420616313a3b4bc95a9effa00363cf3ad953e6

[lldb-dev] printf works under lldb but not otherwise

[Peter Rowat via lldb-dev]

I have a simple C program that has printf statements.
It produces zero output.
However when it’s run under lldb, it prints correct output. How could this be?

I tried replacing the printf statements by “fprintf” to a file: same behaviour -
   no file created and no output, but under lldb, the file is created with 
correct output data.

Peter R






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

[lldb-dev] [Bug 43599] New: lldb can not print anonymous structs anymore

[via lldb-dev]

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

Bug ID: 43599
   Summary: lldb can not print anonymous structs anymore
   Product: lldb
   Version: 9.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: nat-llvmb...@mulle-kybernetik.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

Created attachment 22641
  --> https://bugs.llvm.org/attachment.cgi?id=22641&action=edit
Sourcecode

Build with `clang -o foo -g -O0 foo.c.`
Then load foo into lldb and set a breakpoint on main.
Execute until printf. Now say `p x`.

You'll get ((anonymous struct)) $0 = {}

Here's some log output

lldb FindExternalLexicalDecls[2] on (ASTContext*)0x13f1120 in ''
(CXXRecordDecl*)0x1430e48
lldb   FELD[2] Original decl (ASTContext*)0x7f9b98005b20
(Decl*)0x7f9b98047638:
lldb struct {
lldb int x;
lldb int y;
lldb }
lldb   FELD[2] Adding [to CXXRecordDecl ] lexical FieldDecl int x
lldb   FELD[2] Adding [to CXXRecordDecl ] lexical FieldDecl int y
lldb LayoutRecordType[3] on (ASTContext*)0x13f1120 for
(RecordDecl*)0x1430e48 [name = '']
lldb LRT[3] returned:
lldb LRT[3]   Original = (RecordDecl*)0x7f9b98047638
lldb LRT[3]   Size = 64
lldb LRT[3]   Alignment = 32
lldb LRT[3]   Fields:
lldb LRT[3]   Bases:
lldb EntityVariable::Dematerialize [address = 0x77fcc008,
m_variable_sp = x]
lldb == [UserExpression::Evaluate] Execution completed normally
with result (null) ==
lldb IRMemoryMap::Free (0x77d17000) freed
[0x77d17000..0x77d97007)
lldb IRMemoryMap::Free (0x77fcc000) freed
[0x77fcc000..0x77fcc017)
((anonymous struct)) $1 = {}

Its puzzling, because you can see the expr is actually completing the
record_decl correctly. Bbut then llvm throws the result away in
IRForTarget::CreateResultVariable I believe, by asking the Parser, who returns
an incomplete RecordDecl ?


   304} else {
   305  m_result_type = lldb_private::TypeFromParser(
   306  result_var->getType().getAsOpaquePtr(),
   307  lldb_private::ClangASTContext::GetASTContext(
   308  &result_decl->getASTContext()));
   309}

The same procedure works fine with 8.0.0.

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

Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

[Larry D'Anna via lldb-dev]

Pavel Labath said

> some llvm classes, are so well-known and widely used, that qualifying 
> them with "llvm::" serves no useful purpose and only adds visual noise. 
> I'm thinking here mainly of ADT classes like String/ArrayRef, 
> Optional/Error, etc. I propose we stop explicitly qualifying these classes.
> 
> We can implement this proposal the same way as clang solved the same 
> problem, which is by creating a special LLVM.h 
>  
> header in the Utility library. This header would adopt these classes 
> into the lldb_private namespace via a series of forward and "using" 
> declarations.
> 
> I think clang's LLVM.h is contains a well-balanced collection of adopted 
> classes, and it should cover the most widely-used classes in lldb too, 
> so I propose we use that as a starting point.

I think this is a great idea, particularly for llvm::Expected.   The signatures 
of functions 
using Expected arer kind of noisy already, and adding llvm:: doesn’t help.

Anyone object to this idea?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev