polyakov.alex added a comment. In https://reviews.llvm.org/D47302#1111377, @clayborg wrote:
> In https://reviews.llvm.org/D47302#1111372, @polyakov.alex wrote: > > > In https://reviews.llvm.org/D47302#1111351, @clayborg wrote: > > > > > In https://reviews.llvm.org/D47302#1111249, @polyakov.alex wrote: > > > > > > > In https://reviews.llvm.org/D47302#1111078, @clayborg wrote: > > > > > > > > > It might make sense to create a new SBTargetSettings class that has > > > > > accessors. Then we can have to accessors on SBTarget: > > > > > > > > > > class SBTarget { > > > > > static SBTargetSettings GetGlobalSettings(); > > > > > SBTargetSettings GetSettings(); > > > > > }; > > > > > > > > > > > > > > > > > What global settings should be in your opinion? I guess that they > > > > should be stored in the `SBDebugger`, and a typical use case for them > > > > would be: > > > > > > > > SBTarget target; > > > > target.HookUpGlobalSettings; > > > > > > > > > > > > > I would code it exactly as I specified above. Ask the SBTarget for its > > > settings. We would only expose the "target.*" settings through the > > > SBTargetSettings class. SBDebugger could have its own settings for > > > everything that is stored in the Debugger.cpp g_properties variable, > > > those would be in SBDebuggerSettings if we need access to those: > > > > > > class SBDebugger { > > > static SBDebuggerSettings GetGlobalSettings(); > > > SBDebuggerSettings GetSettings(); > > > }; > > > > > > > > > > > > > > > >> This allows us to expose settings in a way that would allow us to > > > >> serialize the settings and then load them again later. > > > >> > > > >> class SBTargetSettings { > > > >> // Accessors for "target...." setting > > > >> void AppendImageSearchPath(const char *from, const char *to); > > > >> size_t GetNumImageSearchPaths(); > > > >> const char *GetImageSearchPathAtIndex(size_t i); > > > >> // Save and load all settings > > > >> void Load(SBStream &s); > > > >> void Save(SBStream &s); > > > >> }; > > > > > > > > Serialization sounds good, but, to accurately understand you, do you > > > > mean "classic" serialization with saving data into the file or > > > > serialization just for the time when debugger is run? > > > > > > SBStream can be a string buffer or a file. We should probably save to > > > JSON and load from JSON. But that doesn't need to be done in this patch. > > > > > > So, for now we'll just save settings to a string buffer? > > > Don't worry about saving/loading in this patch. That was just a proposed > future direction we can easily do once we have the SBTargetOptions class > split out into its own class. So concentrate on making a SBTargetOptions and > optionally the SBDebuggerOptions class if you need access to debugger > settings as well. If I understood you right, the approach is to have a separated class `SBTargetSettings` with own data structures consisting of the settings. Also each instance of `SBTarget` will have a field `SBTargetSettings sb_settings;`. If so, we still need a `SBTarget::AddSharedObjectPath`. Repository: rL LLVM https://reviews.llvm.org/D47302 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
