EDG Module Map

This page is the definitive reference table mapping all 52 .c modules and 13 .h header modules of EDG 6.6 to their binary addresses in the cudafe++ CUDA 13.0 build. Each module is identified by the trailing .c/.h filename of the assertion path-string its functions load. Every column is derived from the .rodata string cross-reference database and verified against the 20 sweep reports (P1.01 through P1.20).

For narrative discussion of these modules and their roles in the compilation pipeline, see the Function Map and EDG Overview pages.

Module Identifiers

Every assertion path-string shares a common prefix ending in EDG_6.6 and terminates in a .c/.h filename. Only that trailing filename is meaningful to this analysis; it is used as the stable identifier for the module a function belongs to.

Coverage Summary

The 34% mapping rate reflects the fact that only functions containing EDG internal_error assertions reference __FILE__ strings. Functions below the assertion threshold, display-only code compiled without assertions, inlined leaf functions, and the statically-linked C++ runtime are all invisible to this technique.

Column Definitions

Module Table — 52 .c Modules

Sorted by main body start address. This ordering reflects the binary layout, which is near-alphabetical with two exceptions noted below.

Module Table — 13 .h Header Modules

Header modules appear in assertion strings when an inline function or macro defined in the header triggers an internal_error call. The function itself is compiled within the .c module's translation unit, but __FILE__ resolves to the header's filename. These functions are scattered across the binary, interleaved with the .c module that #include-d them.

The stub column sums to 217 across the two tables (200 from .c modules + 17 from .h modules). The 198 figure quoted in the narrative counts distinct stub functions referencing any module string — each stub references exactly one module, but 19 stub functions are the target of multiple cross-references (the same stub is reused at multiple assertion call sites that all encode the same location), inflating column sums above the unique-stub count.

Header Distribution Patterns

The 13 headers fall into three distinct patterns:

Localized headers — functions cluster in a single .c module's address range:

• float_type.h (63 funcs in 52 KB at 0x7D1C90--0x7DEB90, all within floating.c)
• walk_entry.h (51 funcs in 90 KB at 0x604170--0x618660, all within il_walk.c)
• modules.h (5 funcs in 5 KB at 0x7C1100--0x7C2560, all within modules.c)
• decls.h, lexical.h, overload.h, symbol_tbl.h (1–2 funcs each, single site)
• mem_manage.h (4 funcs, single site in error.c)

Moderately scattered headers — functions appear in 2–3 .c modules:

• il.h (5 funcs across expr.c, il.c, il_to_str.c)
• scope_stk.h (4 funcs across expr.c, exprutil.c)
• nv_transforms.h (3 funcs across class_decl.c, cp_gen_be.c, src_seq.c)

Pervasive headers — functions inlined into most .c modules:

• util.h (124 xrefs spanning 0x430E10--0x7C2B10, nearly the entire EDG region)
• types.h (17 funcs spanning 0x469260--0x7B05E0, scattered type queries)

Assert Stub Region

The region 0x403300--0x408B40 contains 235 small __noreturn functions. Each encodes a single assertion site: the assertion path-string, line number, and enclosing function name. When the assertion condition fails, the stub calls sub_4F2930 (EDG's internal_error handler) and does not return. Every stub is 29 bytes.

Of the 235 stubs, 198 carry a resolvable module string (181 to .c modules, 17 to .h modules); the remaining 37 are unattributed — their __FILE__ argument is either folded into a shared string or supplied by the caller, and they do not appear as targets in the per-module cross-reference table below.

Stub Distribution by Module

After the stubs, addresses 0x408B40--0x409350 contain 15 C++ static constructor functions (ctor_001 through ctor_015) that initialize global tables at program startup. These have no module attribution.

Gap Analysis — Unmapped Regions

The following address ranges within the EDG .text region contain functions that could not be mapped to any module via __FILE__ strings. Each gap represents functions that either lack assertions entirely, use non-EDG assertion macros, or are compiler-generated (vtable thunks, exception handlers, template instantiation artifacts).

The largest unmapped gap within EDG code proper is the IL display region at 0x5E8300--0x5F7FD0 (87 KB). These functions were compiled from il_to_str.c but contain no assertions because the display/dump subsystem was built without assertion macros — it is purely diagnostic code that formats IL trees to stdout.

Alphabetical Layout Observation

Modules are laid out in the binary in near-alphabetical order by name, a consequence of the build system compiling object files in directory-listing order and the linker processing them sequentially. The sequence is strictly alphabetical from attribute.c through types.c (rows 1–50).

Two modules break this pattern:

Both modules appear after the main alphabetical sequence, placed at the very end of the EDG region. The most likely explanation is that modules.c and floating.c are compiled as separate translation units — perhaps as a secondary build target — and are appended to the link line after the alphabetically-sorted main objects. The modules.c module implements C++20 module support (mostly stubs in the CUDA build), and floating.c implements arbitrary-precision IEEE 754 arithmetic — both are semi-independent subsystems that could plausibly be compiled separately.

Note that floating.c is followed immediately by its private header float_type.h (63 template instantiations at 0x7D1C90--0x7DEB90), confirming they share a compilation unit.

Binary Region Map

0x402A18 +--------------------------+
         | PLT stubs / init (283)   |  3 KB
0x403300 +--------------------------+
         | Assert stubs (198)       |  22 KB
0x408B40 +--------------------------+
         | Constructors (15)        |  2 KB
0x409350 +--------------------------+
         | attribute.c              |  65 KB
0x419280 | class_decl.c             | 190 KB
         | cmd_line.c               |  58 KB
         | const_ints.c             |  16 KB
         | cp_gen_be.c              | 139 KB
         | debug.c                  |  <1 KB
         | decl_inits.c             |  90 KB
         | decl_spec.c              |  73 KB
         | declarator.c             |  50 KB
         | decls.c                  | 165 KB
         | disambig.c               |  10 KB
         | error.c                  |  46 KB
         | expr.c                   | 381 KB
         | exprutil.c               | 176 KB
         | extasm.c                 |   3 KB
         | fe_init.c                |   2 KB
         | fe_wrapup.c              |  <1 KB
         | float_pt.c               |  44 KB
         | folding.c                |  66 KB
         | func_def.c               |  23 KB
         | host_envir.c             |  19 KB
         | il.c                     | 185 KB
         | il_alloc.c               |  31 KB
         | [il display gap]         |  87 KB  (unmapped)
         | il_to_str.c              |  48 KB
         | il_walk.c                | 115 KB
         | interpret.c              | 250 KB
         | layout.c                 |  29 KB
         | lexical.c                | 141 KB
         | literals.c               |  18 KB
         | lookup.c                 |  50 KB
         | lower_name.c             |  60 KB
         | macro.c                  |  42 KB
         | mem_manage.c             |  13 KB
         | nv_transforms.c          |  22 KB
         | overload.c               | 201 KB
         | pch.c                    |  14 KB
         | pragma.c                 |   9 KB
         | preproc.c                |  12 KB
         | scope_stk.c              |  76 KB
         | src_seq.c                |  31 KB
         | statements.c             |  55 KB
         | symbol_ref.c             |  24 KB
         | symbol_tbl.c             | 123 KB
         | sys_predef.c             |  20 KB
         | target.c                 |   2 KB
         | templates.c              | 286 KB
         | trans_copy.c             |  <1 KB
         | trans_corresp.c          |  50 KB
         | trans_unit.c             |   3 KB
         | types.c                  | 112 KB
         |  --- alphabetical break ---
         | modules.c                |   6 KB
         |  --- gap (59 KB) ---
0x7D0EB0 | floating.c               |  19 KB
         | float_type.h inlines     |  52 KB
0x7DFFF0 +--------------------------+
         | C++ runtime / demangler  | 304 KB
0x82A000 +--------------------------+

Reproduction

The reproduction below treats any assertion path-string — a .rodata string whose trailing path component is a .c/.h filename and that is cross-referenced from an assert stub — as a module identifier. The trailing filename is the module key.

To regenerate the module list from the strings database:

jq '[.[] | select(.value | test("\\.[ch]$")) |
  {file: (.value | split("/") | last),
   xrefs: (.xrefs | length)}
] | group_by(.file) |
  map({file: .[0].file,
       total_xrefs: (map(.xrefs) | add)}) |
  sort_by(.file)' cudafe++_strings.json

To extract address ranges per module:

import json
from collections import defaultdict

with open('cudafe++_strings.json') as f:
    data = json.load(f)

modules = defaultdict(list)
for entry in data:
    val = entry.get('value', '')
    # Module strings end in a .c/.h filename (the trailing path component)
    if not (val.endswith('.c') or val.endswith('.h')):
        continue
    fname = val.split('/')[-1]
    for xref in entry.get('xrefs', []):
        modules[fname].append(int(xref['from'], 16))

for fname in sorted(modules):
    addrs = sorted(modules[fname])
    print(f"{fname:25s}  {hex(addrs[0]):>12s} - {hex(addrs[-1]):>12s}"
          f"  ({len(addrs)} xrefs)")

1. nv_transforms.c has only 1 function with an EDG-style __FILE__ reference, but sweep analysis confirms ~40 functions in the 0x6BAE70--0x6BE4A0 region (~22 KB). Most use NVIDIA's own assertion macros instead of EDG's internal_error path. ↩