This is an archive of the discontinued LLVM Phabricator instance.

[LLDB][GUI] Add Environment Variable Field
ClosedPublic

Authored by OmarEmaraDev on Jul 28 2021, 1:21 PM.

Details

Summary

This patch adds an environment variable field. This is usually used as
the basic type of a List field. This is needed to create the process
launch form.

Diff Detail

Event Timeline

OmarEmaraDev created this revision.Jul 28 2021, 1:21 PM
OmarEmaraDev requested review of this revision.Jul 28 2021, 1:21 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 28 2021, 1:21 PM

Example list of environment fields:

clayborg added inline comments.Jul 28 2021, 4:33 PM
lldb/source/Core/IOHandlerCursesGUI.cpp
1924

There are other things that could benefit from having two text fields, like source mapping:

(lldb) apropos target.source-map
No commands found pertaining to 'target.source-map'. Try 'help' to see a complete list of debugger commands.

The following settings variables may relate to 'target.source-map':
  target.source-map -- Source path remappings apply substitutions to the paths of source files, typically needed to debug from a different host than the one that built the
                       target.  The source-map property consists of an array of pairs, the first element is a path prefix, and the second is its replacement.  The syntax is
                       `prefix1 replacement1 prefix2 replacement2...`.  The pairs are checked in order, the first prefix that matches is used, and that prefix is substituted
                       with the replacement.  A common pattern is to use source-map in conjunction with the clang -fdebug-prefix-map flag.  In the build, use
                       `-fdebug-prefix-map=/path/to/build_dir=.` to rewrite the host specific build directory to `.`.  Then for debugging, use `settings set target.source-map .
                       /path/to/local_dir` to convert `.` to a valid local path.

This would be very close to the EnvironmentVariableFieldDelegate class, but instead of "Name" and "Value" the fields would be "Prefix" and "Replacement". In the source map case the two fields would be a DirectoryFieldDelegate objects. So we could make a base class like PairFieldDelegate that much of the functionality in this class could be moved to. The constructor for the PairFieldDelegate could take two "FieldDelegate *" arguments. So then EnvironmentVariableFieldDelegate could inherit from PairFieldDelegate and this constructor would look like:

EnvironmentVariableFieldDelegate(): 
  PairFieldDelegate(new EnvironmentVariableNameFieldDelegate("Name", ""),
                               new TextFieldDelegate("Value", "", /*required=*/false))

Not required, but it might make it a more useful set of reusable classes for this curses field stuff. Let me know if you are up for doing an approach like this or not

  • Generalize the implementation to any Mapping field
OmarEmaraDev marked an inline comment as done.Jul 29 2021, 6:39 AM

I generalized the implementation as suggested and added a ready to use list version of the field.

clayborg accepted this revision.Jul 29 2021, 1:25 PM

Very nice! Looks great.

This revision is now accepted and ready to land.Jul 29 2021, 1:25 PM
This revision was landed with ongoing or failed builds.Jul 29 2021, 1:28 PM
This revision was automatically updated to reflect the committed changes.