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

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

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.


Repository:
  rL LLVM

https://reviews.llvm.org/D47302