[DynInst_API:] [dyninst/dyninst] 9fddc4: Unify naming of Modules (#1500)


Date: Thu, 07 Sep 2023 11:04:31 -0700
From: Tim Haines <noreply@xxxxxxxxxx>
Subject: [DynInst_API:] [dyninst/dyninst] 9fddc4: Unify naming of Modules (#1500)
  Branch: refs/heads/master
  Home:   https://github.com/dyninst/dyninst
  Commit: 9fddc4282879da75ffc456d91d8e70c9d06b091e
      https://github.com/dyninst/dyninst/commit/9fddc4282879da75ffc456d91d8e70c9d06b091e
  Author: Tim Haines <thaines.astro@xxxxxxxxx>
  Date:   2023-09-07 (Thu, 07 Sep 2023)

  Changed paths:
    A dwarf/h/dwarf_cu_info.h
    R dwarf/h/dwarf_cu_info.hpp
    A dwarf/h/dwarf_names.h
    M dyninstAPI/src/BPatch_image.C
    M dyninstAPI/src/mapped_object.C
    M symtabAPI/doc/3-Examples.tex
    M symtabAPI/h/Aggregate.h
    M symtabAPI/src/Aggregate.C
    M symtabAPI/src/Object-elf.C
    M symtabAPI/src/Symtab.C
    M symtabAPI/src/dwarfWalker.C
    M symtabAPI/src/dwarfWalker.h

  Log Message:
  -----------
  Unify naming of Modules (#1500)

* Unify naming of Modules

There are currently several different techniques being used
inconsistently to name Modules. This unifies all of these techniques
and applies them consistently.

Naming type units:

It's not clear from the DWARF std at this time if dwarf_formstring
will actually return the signature/MD5 hash for a type unit. Whatever
the old code has done is likely broken, so we don't want to propagate
that here. Likely, the DW_FORM_ref_sig8 parsing isn't being done
correctly overall, and will need to be fixed in the future.

Anonymous DIEs:

Many DIEs don't have names (e.g., type decorator definitions like
DW_TAG_pointer_type), but DwarfWalker has explicit checks for these
cases (DwarfWalker::nameDefined).

* Remove DEFAULT_MODULE

Because every Module now has a unique name, it's no longer possible to
execute this code path. The 'pmodule' class uses the name from the Module
class (see the pmodule constructor).


[← Prev in Thread] Current Thread [Next in Thread→]
  • [DynInst_API:] [dyninst/dyninst] 9fddc4: Unify naming of Modules (#1500), Tim Haines <=