labath added a comment. If I understand correctly, everyone agrees with this change, so I will commit it soon(ish). Below are my thoughs on some of the things said in this thread.
@zturner wrote: > Super awesome. When you do move it to Utility, can you run the deps python > script to see if any cmake dependencies can be updated? The only change necessary was to *add* Utility as a dependency of the ArchitectureArm plugin, which did not depend (directly) on Utility before this. In https://reviews.llvm.org/D39896#922381, @probinson wrote: > Drive by comment: > > Triple.h is in ADT; Triple.cpp is in Support. I agree it belongs in Support, > and I'm not sure why it's schizo like that. That's because there is no `llvm/lib/ADT`, and there couldn't be one in the present form because of all the mutual dependencies between ADT and Support headers. So all of the ADT cpp files live in Support, but it's not so glaringly obvious as most of ADT is header-only. Triple is one of few headers that actually has a cpp file. (That said, I can see some reasoning behind it being in ADT, but I do think it would look better in Support.) > Note, Greg and I used to argue about the strategy for lldb-server. My notion > was on modern systems the actual file size difference between an lldb-server > that used all of lldb.framework, and one that could use a cut down library > was really not all that important. If you're making a stub for an hard > embedded system, you probably aren't going to use lldb-server, you'll use a > much smaller gdb-protocol stub, and we didn't really have the intent to > provide that functionality. So lldb server as intended for things like > phones etc, where "small" means small in modern terms, not "a kilobyte > matters" type small. In our distribution model, we copy the lldb-server to the phone the first time you start a debug session, so size is still important to us (we're not counting every kilobyte, but a megabyte more or less matters). liblldb is currently ~61 MB, while lldb-server (x86_64) is 9.6 (less, when you compile with -Os). Initially, the two numbers were nearly equal. Right now we're mostly happy with the size (although we wouldn't mind it being smaller), so size is not my primary motivation here. In https://reviews.llvm.org/D39896#922134, @zturner wrote: > I'd be open to having another organizational component that isn't Utility. > But as Jim said, there isn't a critical mass of stuff yet in Utility to > figure out where it makes sense to draw the line. > > In all honesty, that second component might just end up being "Core" again, > if enough stuff can be moved out of Core that it doesn't have to depend on > Symbol, Host, Interpreter, Breakpoint, etc. I agree. At one point in not too distant future we will need to sit down and figure out how to split up Utility (otherwise, the layering problem can be vacuously "solved" by moving everything into a single layer). I don't think it will be easy though, as there is a natural tendency for the lowest layers of anything to become a collection of random unrelated tidbits (which is what happened to llvm support). My ideas for the next steps are roughly as follows: - move ProcessInfo class and friends to Utility or Host. This is so that the "get me the list of processes on this machine" functionality can work without including Process.h - move the symbol-finding code from Host to Platform -- most of this is not host- but target-specific. E.g. the linux way of finding symbols could easily work for remote debugging from other OSes, if you had a suitable sysroot copied or network-mounted. - move RegisterValue to Utility -- useful in lldb-server, unlike a lot of the stuff in Core. https://reviews.llvm.org/D39896 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
