summaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ObjectFile/JSON
AgeCommit message (Collapse)Author
2025-06-04[lldb/cmake] Implicitly pass arguments to llvm_add_library (#142583)Pavel Labath
If we're not touching them, we don't need to do anything special to pass them along -- with one important caveat: due to how cmake arguments work, the implicitly passed arguments need to be specified before arguments that we handle. This isn't particularly nice, but the alternative is enumerating all arguments that can be used by llvm_add_library and the macros it calls (it also relies on implicit passing of some arguments to llvm_process_sources).
2025-03-07Add complete ObjectFileJSON support for sections. (#129916)Greg Clayton
Sections now support specifying: - user IDs - file offset/size - alignment - flags - bool values for fake, encrypted and thread specific sections
2025-03-04Add subsection and permissions support to ObjectFileJSON. (#129801)Greg Clayton
This patch adds the ability to create subsections in a section and allows permissions to be specified.
2025-03-04[lldb] Fix ObjectFileJSON to section addresses. (#129648)Greg Clayton
ObjectFileJSON sections didn't work, they were set to zero all of the time. Fixed the bug and fixed the test to ensure it was testing real values.
2023-04-13[lldb] Make ObjectFileJSON loadable as a moduleJonas Devlieghere
This patch adds support for creating modules from JSON object files. This is necessary for the crashlog use case where we don't have either a module or a symbol file. In that case the ObjectFileJSON serves as both. The patch adds support for an object file type (i.e. executable, shared library, etc). It also adds the ability to specify sections, which is necessary in order specify symbols by address. Finally, this patch improves error handling and fixes a bug where we wouldn't read more than the initial 512 bytes in GetModuleSpecifications. Differential revision: https://reviews.llvm.org/D148062
2023-03-08[lldb] Introduce new SymbolFileJSON and ObjectFileJSONJonas Devlieghere
Introduce a new object and symbol file format with the goal of mapping addresses to symbol names. I'd like to think of is as an extremely simple textual symtab. The file format consists of a triple, a UUID and a list of symbols. JSON is used for the encoding, but that's mostly an implementation detail. The goal of the format was to be simple and human readable. The new file format is motivated by two use cases: - Stripped binaries: when a binary is stripped, you lose the ability to do thing like setting symbolic breakpoints. You can keep the unstripped binary around, but if all you need is the stripped symbols then that's a lot of overhead. Instead, we could save the stripped symbols to a file and load them in the debugger when needed. I want to extend llvm-strip to have a mode where it emits this new file format. - Interactive crashlogs: with interactive crashlogs, if we don't have the binary or the dSYM for a particular module, we currently show an unnamed symbol for those frames. This is a regression compared to the textual format, that has these frames pre-symbolicated. Given that this information is available in the JSON crashlog, we need a way to tell LLDB about it. With the new symbol file format, we can easily synthesize a symbol file for each of those modules and load them to symbolicate those frames. Here's an example of the file format: { "triple": "arm64-apple-macosx13.0.0", "uuid": "36D0CCE7-8ED2-3CA3-96B0-48C1764DA908", "symbols": [ { "name": "main", "type": "code", "size": 32, "address": 4294983568 }, { "name": "foo", "type": "code", "size": 8, "address": 4294983560 } ] } Differential revision: https://reviews.llvm.org/D145180