5 Commits

Author SHA1 Message Date
Greg Clayton
8ac359ba0d
Add complete ObjectFileJSON support for sections. (#129916)
Sections now support specifying:
- user IDs
- file offset/size
- alignment
- flags
- bool values for fake, encrypted and thread specific sections
2025-03-07 15:34:27 -08:00
Greg Clayton
27901cec0e
Add subsection and permissions support to ObjectFileJSON. (#129801)
This patch adds the ability to create subsections in a section and
allows permissions to be specified.
2025-03-04 16:19:20 -08:00
Greg Clayton
7b596ce362
[lldb] Fix ObjectFileJSON to section addresses. (#129648)
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.
2025-03-04 14:35:42 -08:00
Jonas Devlieghere
0e5cdbf07e
[lldb] Make ObjectFileJSON loadable as a module
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-04-13 14:08:19 -07:00
Jonas Devlieghere
cf3524a574
[lldb] Introduce new SymbolFileJSON and ObjectFileJSON
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
2023-03-08 20:56:11 -08:00