Tweaked this, addressing Greg's initial comment (although by different means):
svn commit Sending tools/lldb-gdbserver/lldb-gdbserver.cpp Transmitting file data . Committed revision 216581. On Tue, Aug 26, 2014 at 3:08 PM, Todd Fiala <[email protected]> wrote: > One of the reasons we do want to do this at some point is to ensure we > don't start creeping into using larger portions of the codebase than we > intend. > > I was going to also add a test around the building of llgs once we have a > release build that uses static libraries and dead code elimination, and > have it fail if it gets beyond a certain size. More of a warning if we go > from 45 MB to something like 150 MB. > > -Todd > > > On Tue, Aug 26, 2014 at 3:04 PM, Todd Fiala <[email protected]> wrote: > >> (In all seriousness, yes that would be good to do at some point - >> effectively what I was saying earlier was having a core that is shared >> between low level exes (lldb-gdbserver, lldb-platform, minimal as >> possible). We're looking into doing that possibly at some point. It's a >> little more than we want to take on in the short term, though. >> >> >> On Tue, Aug 26, 2014 at 3:03 PM, Todd Fiala <[email protected]> wrote: >> >>> I'm picking my battles in the interest of getting things done, Zach :-P >>> >>> >>> On Tue, Aug 26, 2014 at 3:02 PM, Zachary Turner <[email protected]> >>> wrote: >>> >>>> I feel like relying on dead code elimination is a crutch to workaround >>>> an improperly layered set of libraries. It gets the job done with the >>>> least amount of programmer effort involved, but it might be worth at least >>>> brainstorming a better long-term solution and finding a way to split the >>>> libraries apart in such a way that llgs can bring in only the things it >>>> needs. Even if doing the actual split up front might be untenable due to >>>> time constraints or other factors, having a clear direction regarding an >>>> "end state" would perhaps allow new code to get fit into this model when >>>> it's written, and refactoring toward the end goal to happen gradually over >>>> time, as time permits. >>>> >>>> >>>> On Tue, Aug 26, 2014 at 12:21 PM, Todd Fiala <[email protected]> wrote: >>>> >>>>> So here I *think* we want to do something that will let the linker >>>>> dead code elimination be able to figure out which modules it doesn't need. >>>>> Which means I think we really want the call graph for initializing the >>>>> lighter apps (lldb-platform, lldb-gdbserver) to have a method they call >>>>> which initializes the always-present items (i.e. the core). Then we can >>>>> have the heavier apps (lldb) call the core initialization, then layer on >>>>> the higher-level systems. >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Todd Fiala <[email protected]> >>>>> Date: Tue, Aug 26, 2014 at 12:18 PM >>>>> Subject: Re: [Lldb-commits] [lldb] r216238 - Add missing >>>>> HostInfo::Initialize() in llgs. >>>>> To: Greg Clayton <[email protected]> >>>>> Cc: Todd Fiala <[email protected]>, lldb-commits < >>>>> [email protected]> >>>>> >>>>> >>>>> Ok back looking at this for real. >>>>> >>>>> So I'm going to need to adjust Debugger::Initalize() or use an >>>>> alternative installation path. Right now it goes and calls >>>>> lldb_private::Initialize(), which pretty much brings in the whole world. >>>>> llgs needs to be *thin*, as we're counting on static linkage and dead >>>>> code >>>>> elimination to cut out the bulk of the exe size. There is a ton more >>>>> stuff >>>>> initialized in lldb_private::Initialize() than we need in llgs. >>>>> >>>>> (e.g. ProcessLinux, DynamicLoader*, language runtimes, etc. --- none >>>>> of those should be getting initialized in llgs). >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Aug 26, 2014 at 11:52 AM, Todd Fiala <[email protected]> >>>>> wrote: >>>>> >>>>>> Ok - but - are we okay with moving PluginManager::Initialize() within >>>>>> there? If so, we're good. Because HostInfo::Initialize() needs to come >>>>>> *before* PluginManager::Initialize(). >>>>>> >>>>>> Seems reasonable, I just need to peek where we're initializing >>>>>> PluginManager. >>>>>> >>>>>> >>>>>> On Tue, Aug 26, 2014 at 11:51 AM, Greg Clayton <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> then HostInfo::Initialize() should go first within >>>>>>> Debugger::Initialize() and HostInfo::Terminate() should go last in >>>>>>> Debugger::Terminate(). >>>>>>> >>>>>>> > On Aug 26, 2014, at 11:46 AM, Todd Fiala <[email protected]> >>>>>>> wrote: >>>>>>> > >>>>>>> > > But I think Debugger depends on HostInfo being initialized first. >>>>>>> > >>>>>>> > Rather I meant: >>>>>>> > * PluginManager::Initialize() requires HostInfo to already be >>>>>>> initialized. >>>>>>> > * Debugger::Initialize() expects PluginManager is already >>>>>>> initialized. >>>>>>> > >>>>>>> > >>>>>>> > On Tue, Aug 26, 2014 at 11:44 AM, Todd Fiala <[email protected]> >>>>>>> wrote: >>>>>>> > There might be an issue there. >>>>>>> > >>>>>>> > PluginManager uses the file system initialization. But I think >>>>>>> Debugger depends on HostInfo being initialized first. >>>>>>> > >>>>>>> > I'll look and see if I can detangle that. >>>>>>> > >>>>>>> > >>>>>>> > On Tue, Aug 26, 2014 at 11:43 AM, Todd Fiala <[email protected]> >>>>>>> wrote: >>>>>>> > Ah ok. I'll move those in a minute. Another check-in coming >>>>>>> shortly before. >>>>>>> > >>>>>>> > >>>>>>> > On Tue, Aug 26, 2014 at 11:34 AM, Greg Clayton <[email protected]> >>>>>>> wrote: >>>>>>> > Todd: >>>>>>> > >>>>>>> > HostInfo::Intialize() should be done in Debugger::Initialize() >>>>>>> > HostInfo::Terminate() should be done in Debugger::Terminate() >>>>>>> > >>>>>>> > We want there to be single call to initialize everything and >>>>>>> terminate everything and this is done via the Debugger calls. >>>>>>> > >>>>>>> > > On Aug 21, 2014, at 3:41 PM, Todd Fiala <[email protected]> >>>>>>> wrote: >>>>>>> > > >>>>>>> > > Author: tfiala >>>>>>> > > Date: Thu Aug 21 17:41:25 2014 >>>>>>> > > New Revision: 216238 >>>>>>> > > >>>>>>> > > URL: http://llvm.org/viewvc/llvm-project?rev=216238&view=rev >>>>>>> > > Log: >>>>>>> > > Add missing HostInfo::Initialize() in llgs. >>>>>>> > > >>>>>>> > > This fixes an llgs segfault on startup. >>>>>>> > > >>>>>>> > > Modified: >>>>>>> > > lldb/trunk/tools/lldb-gdbserver/lldb-gdbserver.cpp >>>>>>> > > >>>>>>> > > Modified: lldb/trunk/tools/lldb-gdbserver/lldb-gdbserver.cpp >>>>>>> > > URL: >>>>>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-gdbserver/lldb-gdbserver.cpp?rev=216238&r1=216237&r2=216238&view=diff >>>>>>> > > >>>>>>> ============================================================================== >>>>>>> > > --- lldb/trunk/tools/lldb-gdbserver/lldb-gdbserver.cpp (original) >>>>>>> > > +++ lldb/trunk/tools/lldb-gdbserver/lldb-gdbserver.cpp Thu Aug >>>>>>> 21 17:41:25 2014 >>>>>>> > > @@ -32,6 +32,7 @@ >>>>>>> > > #include "lldb/Core/Debugger.h" >>>>>>> > > #include "lldb/Core/PluginManager.h" >>>>>>> > > #include "lldb/Core/StreamFile.h" >>>>>>> > > +#include "lldb/Host/HostInfo.h" >>>>>>> > > #include "lldb/Host/OptionParser.h" >>>>>>> > > #include "lldb/Host/Socket.h" >>>>>>> > > #include "lldb/Interpreter/CommandInterpreter.h" >>>>>>> > > @@ -152,6 +153,7 @@ dump_available_platforms (FILE *output_f >>>>>>> > > static void >>>>>>> > > initialize_lldb_gdbserver () >>>>>>> > > { >>>>>>> > > + HostInfo::Initialize (); >>>>>>> > > PluginManager::Initialize (); >>>>>>> > > Debugger::Initialize (NULL); >>>>>>> > > } >>>>>>> > > @@ -159,7 +161,7 @@ initialize_lldb_gdbserver () >>>>>>> > > static void >>>>>>> > > terminate_lldb_gdbserver () >>>>>>> > > { >>>>>>> > > - Debugger::Terminate(); >>>>>>> > > + Debugger::Terminate (); >>>>>>> > > PluginManager::Terminate (); >>>>>>> > > } >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > _______________________________________________ >>>>>>> > > lldb-commits mailing list >>>>>>> > > [email protected] >>>>>>> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > lldb-commits mailing list >>>>>>> > [email protected] >>>>>>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > Todd Fiala | Software Engineer | [email protected] | >>>>>>> 650-943-3180 >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > Todd Fiala | Software Engineer | [email protected] | >>>>>>> 650-943-3180 >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > Todd Fiala | Software Engineer | [email protected] | >>>>>>> 650-943-3180 >>>>>>> > >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>>>> >>>>> >>>>> >>>>> -- >>>>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>>>> >>>>> _______________________________________________ >>>>> lldb-dev mailing list >>>>> [email protected] >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>>> >>>>> >>>> >>> >>> >>> -- >>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>> >> >> >> >> -- >> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >> > > > > -- > Todd Fiala | Software Engineer | [email protected] | 650-943-3180 > -- Todd Fiala | Software Engineer | [email protected] | 650-943-3180
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
