mirror of
https://github.com/ioacademy-jikim/debugging
synced 2025-06-08 00:16:11 +00:00
60 lines
2.7 KiB
Plaintext
60 lines
2.7 KiB
Plaintext
|
|
Our long term goal is to move to structure Valgrind's top level as a
|
|
set of well-defined modules. Much of the difficulty in maintaining
|
|
the beast is caused by the lack of clear boundaries, definitions and
|
|
semantics for subsystems (modules), and in particular a lack of
|
|
clarity about which modules may depend on which others. The ongoing
|
|
modularisation activities are aimed at dealing with this problem.
|
|
|
|
Architecture dependent stuff will be chopped up and placed into the
|
|
relevant modules. Since the system's top level is now to be
|
|
structured as modules with clearly delimited areas of functionality,
|
|
directories such as 'amd64', 'amd64-linux', etc, cannot continue to
|
|
exist long-term. These trees contain mish-mashes of functionality
|
|
from multiple different modules, and so make no sense as top-level
|
|
entities in a scheme where all top-level entities are modules.
|
|
|
|
This process is ongoing. Consequently some of the code in coregrind/
|
|
has been bought into the module structure, but much hasn't. A naming
|
|
scheme distinguishes the done vs not-done stuff:
|
|
|
|
Consider a module of name 'foo'.
|
|
|
|
If 'foo' is implemented in a single C file, and requires no other
|
|
files, it will live in coregrind/m_foo.c.
|
|
|
|
Otherwise (if 'foo' requires more than one C file, or more than
|
|
zero private header files, or any other kind of auxiliary stuff)
|
|
then it will live in the directory coregrind/m_foo.
|
|
|
|
Each module 'foo' must have two associated header files which describe
|
|
its public (exported) interface:
|
|
|
|
include/pub_tool_foo.h
|
|
coregrind/pub_core_foo.h
|
|
|
|
pub_tool_foo.h describes that part of the module's functionality that
|
|
is visible to tools. Hopefully this can be minimal or zero. If there
|
|
is nothing to visible to tool, pub_tool_foo.h can be omitted.
|
|
|
|
pub_core_foo.h describes functionality that is visible to other
|
|
modules in the core. This is a strict superset of the visible-to-tool
|
|
functionality. Consequently, pub_core_foo.h *must* #include
|
|
pub_tool_foo.h, if it exists. pub_tool_foo.h *must not* #include
|
|
pub_core_foo.h, nor any other pub_core_ header for that matter.
|
|
|
|
Module-private headers are named "priv_foo.h".
|
|
|
|
No module may include the private headers of any other module. If a
|
|
type/enum/function/struct/whatever is stated in neither
|
|
include/pub_tool_foo.h nor coregrind/pub_core_foo.h then module 'foo'
|
|
DOES NOT EXPORT IT.
|
|
|
|
Over time it is hoped to develop some simple Perl scripts to scan
|
|
source files for #includes so as to mechanically enforce these rules.
|
|
One of the most infuriating aspects of C is the total lack of support
|
|
for building properly abstracted subsystems. This is in sharp
|
|
comparison to languages such as Modula3, Haskell, ML, all of which
|
|
have support for modules built into the language, and hence such
|
|
boundaries are enforceable by the compiler.
|