[Lldb-commits] [PATCH] D47302: [lldb, lldb-mi] Add method AddCurrentTargetSharedObjectPath to the SBDebugger.

[Alexander Polyakov via Phabricator via lldb-commits]

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