labath added a comment.

In D70886#1767654 <>, @aadsm wrote:

> > Maybe you could do something similar to LocalLLDBInit.test ?
> That test uses the `lldb` `-S` (and others) flags that `lldb-vscode` doesn't 
> support :(. These flags should really be added to the initialize packet but 
> they're very specific to lldb and the DAP doesn't support it.. We could 
> implement something like what `Driver::ProcessArgs` does and pass options 
> through envs but, the logic in ProcessArgs itself is sketchy (just like the 
> comment mentions) and I l also find it odd to pass options through env vars...

I was specifically referring to the part where the test sets up an `.lldbinit` 
in a random directory and then points the HOME environment variable there in 
order to "trick" lldb into executing it. It's true that the test also uses 
`-S`/`--source-before-file`, but nothing in there is really needed to test this 
functionality (i.e., making sure that lldb-vscode handles the lldbinit file 
reasonably -- making sure that it does not get confused by ambient lldbinit 
files is a different topic).

As for -no-lldbinit functionality, all of the proposed solutions (cmdline flag, 
environment variable, protocol flag...) seem reasonable to me. The environment 
variable is probably easiest to implement, and should be sufficient if we only 
want to use this for testing....

  rG LLVM Github Monorepo


lldb-commits mailing list

Reply via email to