JakeHillion/drgn
1
0
Fork 0
mirror of https://github.com/JakeHillion/drgn.git synced 2024-12-23 01:33:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
bf95af8c0d
drgn/libdrgn/.gitignore

21 lines
241 B
Plaintext
Raw Normal View History

Rewrite drgn core in C The current mixed Python/C implementation works well, but it has a couple of important limitations: - It's too slow for some common use cases, like iterating over large data structures. - It can't be reused in utilities written in other languages. This replaces the internals with a new library written in C, libdrgn. It includes Python bindings with mostly the same public interface as before, with some important improvements: - Types are now represented by a single Type class rather than the messy polymorphism in the Python implementation. - Qualifiers are a bitmask instead of a set of strings. - Bit fields are not considered a separate type. - The lvalue/rvalue terminology is replaced with reference/value. - Structure, union, and array values are better supported. - Function objects are supported. - Program distinguishes between lookups of variables, constants, and functions. The C rewrite is about 6x as fast as the original Python when using the Python bindings, and about 8x when using the C API directly. Currently, the exposed API in C is fairly conservative. In the future, the memory reader, type index, and object index APIs will probably be exposed for more flexibility.
2019-03-22 23:27:46 +00:00
*.la
*.lo
*.o
.deps/
Build Python bindings with automake I went back and forth on using setuptools or autotools for the Python extension, but I eventually settled on using only setuptools after fighting to get the two to integrate well. However, setuptools is kind of crappy; for one, it rebuilds every source file when rebuilding the extension, which is really annoying for development. automake is a better designed build system overall, so let's use that for the extension. We override the build_ext command to build using autotools and copy things where setuptools expects them.
2019-04-03 19:33:37 +01:00
.dirstamp
Rewrite drgn core in C The current mixed Python/C implementation works well, but it has a couple of important limitations: - It's too slow for some common use cases, like iterating over large data structures. - It can't be reused in utilities written in other languages. This replaces the internals with a new library written in C, libdrgn. It includes Python bindings with mostly the same public interface as before, with some important improvements: - Types are now represented by a single Type class rather than the messy polymorphism in the Python implementation. - Qualifiers are a bitmask instead of a set of strings. - Bit fields are not considered a separate type. - The lvalue/rvalue terminology is replaced with reference/value. - Structure, union, and array values are better supported. - Function objects are supported. - Program distinguishes between lookups of variables, constants, and functions. The C rewrite is about 6x as fast as the original Python when using the Python bindings, and about 8x when using the C API directly. Currently, the exposed API in C is fairly conservative. In the future, the memory reader, type index, and object index APIs will probably be exposed for more flexibility.
2019-03-22 23:27:46 +00:00
.libs/
/Makefile
/Makefile.in
/aclocal.m4
/autom4te.cache
/config.log
/config.status
/configure
libdrgn: add configure~ to .gitignore Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-04-23 17:18:16 +01:00
/configure~
Rewrite drgn core in C The current mixed Python/C implementation works well, but it has a couple of important limitations: - It's too slow for some common use cases, like iterating over large data structures. - It can't be reused in utilities written in other languages. This replaces the internals with a new library written in C, libdrgn. It includes Python bindings with mostly the same public interface as before, with some important improvements: - Types are now represented by a single Type class rather than the messy polymorphism in the Python implementation. - Qualifiers are a bitmask instead of a set of strings. - Bit fields are not considered a separate type. - The lvalue/rvalue terminology is replaced with reference/value. - Structure, union, and array values are better supported. - Function objects are supported. - Program distinguishes between lookups of variables, constants, and functions. The C rewrite is about 6x as fast as the original Python when using the Python bindings, and about 8x when using the C API directly. Currently, the exposed API in C is fairly conservative. In the future, the memory reader, type index, and object index APIs will probably be exposed for more flexibility.
2019-03-22 23:27:46 +00:00
/html
/libtool
libdrgn: language_c: replace c_keywords with memswitch GCC or binutils on Fedora Rawhide for ARM seems to have a bug where c_keywords gets placed in the .data.rel.ro section (see https://www.airs.com/blog/archives/189): $ readelf -s .libs/libdrgnimpl_la-language_c.o | grep -w c_keywords 475: 00000000 16 OBJECT LOCAL DEFAULT 175 c_keywords $ readelf -S .libs/libdrgnimpl_la-language_c.o | grep -F '[175]' [175] .data.rel PROGBITS 00000000 051f90 000010 00 WA 0 0 4 $ readelf -s .libs/_drgn.so | grep -w c_keywords 9267: 0008e84c 16 OBJECT LOCAL DEFAULT 21 c_keywords.lto_priv.0 $ readelf -S .libs/_drgn.so | grep -F '[21]' [21] .data.rel.ro PROGBITS 0008e018 07e018 000a10 00 WA 0 0 8 This results in a crash on startup when c_keywords_init() attempts to populate c_keywords. While this appears to be a compiler or linker bug, I've been meaning to replace c_keywords with a static lookup function anyways. Now that we have gen_strswitch.py, we can use it to generate the lookup function. Add a script, gen_c_keywords_inc_strswitch.py, which generates an array mapping token kind to spelling, and a memswitch mapping spelling to token kind. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-02-05 01:17:31 +00:00
/c_keywords.inc
libdrgn: use memswitch for linux_kernel_object_find Replace the hand-written if-else ladder of memcmp() calls with a memswitch. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-02-08 09:32:28 +00:00
/linux_kernel_object_find.inc
Build Python bindings with automake I went back and forth on using setuptools or autotools for the Python extension, but I eventually settled on using only setuptools after fighting to get the two to integrate well. However, setuptools is kind of crappy; for one, it rebuilds every source file when rebuilding the extension, which is really annoying for development. automake is a better designed build system overall, so let's use that for the extension. We override the build_ext command to build using autotools and copy things where setuptools expects them.
2019-04-03 19:33:37 +01:00
/python/constants.c
Document with Sphinx drgn has pretty thorough in-program documentation, but it doesn't have a nice overview or introduction to the basic concepts. This commit adds that using Sphinx. In order to avoid documenting everything in two places, the libdrgn bindings have their docstrings generated from the API documentation. The alternative would be to use Sphinx's autodoc extension, but that's not as flexible and would also require building the extension to build the docs. The documentation for the helpers is generated using autodoc and a small custom extension.
2019-04-04 09:27:23 +01:00
/python/docstrings.c
Reference in New Issue Copy Permalink