Fixing TestSettings.py for remote targets

Hi all,

settings set target.error-path stderr.txt automatically resolves stderr.txt to the local file system.

(lldb) settings set target.error-path stderr.txt
(lldb) settings show target.error-path
target.error-path (file) = “/usr/local/google/home/vharron/ll/tot/lldb/test/stderr.txt”

This doesn’t make any sense for remote targets

(lldb) platform select remote-linux
(lldb) platform connect connect://192.168.100.132:5432

(lldb) platform settings --working-dir /tmp

(lldb) settings set target.error-path stderr.txt

(lldb) settings show target.error-path
target.error-path (file) = “/usr/local/google/home/vharron/ll/tot/lldb/test/stderr.txt”

I propose that we don’t resolve target.error-path or target.output-path but leave it as-is and let the platform interpret it. This probably means the file will be created relative to the working directory of the remote process.

When you call “settings show target.error-path” it will just return the original error string passed to “settings set target.error-path” (e.g. I’ll change it from OptionValueFileSpec to OptionValueString.)

Thoughts?

Vince

This is more fallout from the FileSpec changes Zach made a while back. Debugging shell program that we used to find in the current path is broken too:

% xcrun lldb ls
(lldb) target create "ls"
error: unable to find executable for '/tmp/ls'

It used to be left alone, but now it resolves the file to the current working directory.

Hi all,

settings set target.error-path stderr.txt automatically resolves stderr.txt to the local file system.

(lldb) settings set target.error-path stderr.txt
(lldb) settings show target.error-path
target.error-path (file) = "/usr/local/google/home/vharron/ll/tot/lldb/test/stderr.txt"

This doesn't make any sense for remote targets

(lldb) platform select remote-linux
(lldb) platform connect connect://192.168.100.132:5432
(lldb) platform settings --working-dir /tmp
(lldb) settings set target.error-path stderr.txt
(lldb) settings show target.error-path
target.error-path (file) = "/usr/local/google/home/vharron/ll/tot/lldb/test/stderr.txt"

I propose that we don't resolve target.error-path or target.output-path but leave it as-is and let the platform interpret it. This probably means the file will be created relative to the working directory of the remote process.

When you call "settings show target.error-path" it will just return the original error string passed to "settings set target.error-path" (e.g. I'll change it from OptionValueFileSpec to OptionValueString.)

It is fine for the option for "error-path" to say "don't resolve me". You need to leave this as a OptionValueFileSpec, but we need to tell OptionValueFileSpec to not resolve the path. We need a new bool on this class, something like:

In Propert.cpp we have a constructor for a Property that creates itself from a PropertyDefinition:

Property (const PropertyDefinition &definition)

In this code we have:

        case OptionValue::eTypeFileSpec:
            // "definition.default_uint_value" represents if the "definition.default_cstr_value" should
            // be resolved or not
            m_value_sp.reset (new OptionValueFileSpec(FileSpec(definition.default_cstr_value, definition.default_uint_value != 0)));
            break;

Note in the definition the "definition.default_uint_value" contains if the value should be resolved. We need to modify the constructor for OptionValueFileSpec to take a FileSpec (like it does already) and a bool that says if we are supposed to resolve the path and store that in the class. Any assignments need to respect this flag.

We just need to switch this code to be:

        case OptionValue::eTypeFileSpec:
            // "definition.default_uint_value" represents if the "definition.default_cstr_value" should
            // be resolved or not
            const bool resolve = definition.default_uint_value != 0;
            m_value_sp.reset (new OptionValueFileSpec(FileSpec(definition.default_cstr_value, resolve)), resolve);
            break;