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.
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.
I’m picking my battles in the interest of getting things done, Zach
(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.
Sure, but that’s why I said it might be worth at least brainstorming a better way to organize it. Doesn’t mean anyone has to tackle that right now, but just knowing what a better separation might look like is useful in and of itself.
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.
Tweaked this, addressing Greg’s initial comment (although by different means):
Transmitting file data .
Committed revision 216581.