Page MenuHomePhabricator

Introduce the "Formats" module and move LinuxProcMaps parser to it
AbandonedPublic

Authored by labath on Mar 5 2019, 8:20 AM.

Details

Summary

This patch introduces a "Formats" library, whose goal is to contain
serialization and deserialization code for various textual and binary
formats that lldb needs to work with. The motivation is to enable
building various tools on top of this, which do not need to depend on
the entire lldb codebase. (I have written a slightly more elaborate
version of this is given in the lldb architecture docs, which I update
to mention the new library).

LinuxProcMaps is just the beginning here. As the next immediate step I
plan to move the Minidump parsing code (currently burried in
source/Plugins/Process/minidump) here as well, but in the future I think
this library could contain the gdb-remote protocol code (currently in
source/Plugins/Process/gdb-remote) and the debug info protocol code
(currently in Zach's head).

Event Timeline

labath created this revision.Mar 5 2019, 8:20 AM
zturner accepted this revision.Mar 5 2019, 11:12 AM

Great idea, this is a nice analogue to LLVM/BinaryFormat.

But, "Formats" is a little generic. What about FileFormats or something?

This revision is now accepted and ready to land.Mar 5 2019, 11:12 AM

FileFormats wouldn't be generic enough to capture the gdb-remote or debug-info-server protocol code. However, even calling gdb-remote protocol a "format" is still a bit of a stretch. I think there is enough similarity between gdb-remote and minidump code for them to be in the same module (both convert some (and often the same) data structures into some (file or wire) format), but they're also sufficiently different for them to live in different places. So yeah, if we want the protocol code to live in a different library (Protocols ?), then FileFormats is a better name here.

FileFormats wouldn't be generic enough to capture the gdb-remote or debug-info-server protocol code. However, even calling gdb-remote protocol a "format" is still a bit of a stretch. I think there is enough similarity between gdb-remote and minidump code for them to be in the same module (both convert some (and often the same) data structures into some (file or wire) format), but they're also sufficiently different for them to live in different places. So yeah, if we want the protocol code to live in a different library (Protocols ?), then FileFormats is a better name here.

I was going to propose Protocols for consideration but that doesn't really work for minidump. Thinking a little about this, Formats, although generic, is probably the best.

JDevlieghere accepted this revision.Mar 5 2019, 12:58 PM
labath planned changes to this revision.Mar 6 2019, 7:06 AM

I'm going to wait to see how the llvm option pans out. If minidump parsing code ends up there, we lose the biggest customer of this and so we may revisit the name and/or scope of the new module.

labath abandoned this revision.Mar 21 2019, 3:57 AM

minidump parser will go into llvm, which removes the main incentive for creating this new module. It's possible we may need something like this in the future, but should wait until there is a real use case for it.