drgn/.gitignore

*.pyc
*.so
/.coverage
/.mypy_cache
/build
/coverage.info
/cscope.*
/dist
/docs/_build
/drgn.egg-info
/htmlcov
__pycache__
Initial commit I wrote all of this code a few months back and am just now getting around to committing it. The low-level DWARF parsing library is pretty solid, although it only implements a subset of DWARF so far. The CLI and higher-level interface are experimental. 2017-08-25 06:46:16 +01:00			`*.pyc`
			`*.so`
Add Python coverage output to .gitignore 2018-07-17 03:42:32 +01:00			`/.coverage`
			`/.mypy_cache`
Initial commit I wrote all of this code a few months back and am just now getting around to committing it. The low-level DWARF parsing library is pretty solid, although it only implements a subset of DWARF so far. The CLI and higher-level interface are experimental. 2017-08-25 06:46:16 +01:00			`/build`
			`/coverage.info`
Add scripts/cscope.sh For generating the cscope index from the proper files. 2020-04-28 01:07:15 +01:00			`/cscope.*`
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			`/dist`
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			`/docs/_build`
Add Python coverage output to .gitignore 2018-07-17 03:42:32 +01:00			`/drgn.egg-info`
			`/htmlcov`
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			`__pycache__`