build_notype_import: narrow .dynsym to a symbol table before iterating

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Problem

pyright reports one error in tests_src/ppc64_notype_import/build_notype_import.py,
the script that builds tests/ppc64/fauxware_notype_import:

build_notype_import.py:45 - error: Cannot access attribute "iter_symbols" for class "Section"
    Attribute "iter_symbols" is unknown (reportAttributeAccessIssue)

The file is new, so the angr/mono badness ratchet scores it against an empty
baseline and fails it.

Root cause

ELFFile.get_section_by_name returns a Section, and iter_symbols is defined
on SymbolTableSection. The existing if dynsym is None guard rules out a
missing section but leaves the type as the base Section, which has no
iter_symbols.

Fix

Check isinstance(dynsym, SymbolTableSection) instead. That is the condition
the loop below actually needs, and a file whose .dynsym is not a symbol table
now exits with a message rather than an AttributeError.

Testing

The script still rebuilds the committed tests/ppc64/fauxware_notype_import
byte for byte, sha256
59cadd8413d3f97f2642b89a59851300576fd8b58d8c173f9830111311014b3e. pyright goes
from one error to none, so badness goes from 0.1449 to 0.0000.

Validation: #221 (comment)

session: sharpen

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Validation record for head 8eace819d999c709c71cb3dd8f62eba0df6d92d4 against baseline 45819e52da4b643383109eca2885a18c182486e2.

pyright 1.1.411 over the changed file, one invocation from the tree being
scored, badness (errors * 10 + warnings) / lines:

pyright --outputjson --pythonpath <venv>/bin/python \
  tests_src/ppc64_notype_import/build_notype_import.py

file	lines	errors before	badness before	errors after	badness after
tests_src/ppc64_notype_import/build_notype_import.py	69 -> 70	1	0.1449	0	0.0000

Same figures from two environments: a binaries checkout with pyelftools 0.33
resolved from a workspace virtualenv, and the virtualenv of the assembled
multi-component tree the ratchet runs in. The file at the baseline is
byte-identical to the copy in that tree, sha256
d1dc9cd89fcaf4b31639f59686a7fca5d4de7a66eb7cc062d9f25c5420e53ba1.

The script still reproduces its fixture. Run on the head, over the committed
tests/ppc64/fauxware, it prints

exit: st_info 0x12 -> 0x10
puts: st_info 0x12 -> 0x10

and the file it writes is byte-identical to the committed
tests/ppc64/fauxware_notype_import, sha256
59cadd8413d3f97f2642b89a59851300576fd8b58d8c173f9830111311014b3e before and
after.

Not run: this repository has no test suite, no CI workflow and no pre-commit
configuration, so there is nothing else to run against it. The change touches no
committed binary; git diff --raw against the baseline reports one modified
path, the script itself.

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Full pyright output for the changed file, before and after this change. Paths
are shown relative to the repository root.

Before — one error, on the iter_symbols call:

angr/binaries master

tests_src/ppc64_notype_import/build_notype_import.py
  tests_src/ppc64_notype_import/build_notype_import.py:45:47 - error: Cannot access attribute "iter_symbols" for class "Section"
    Attribute "iter_symbols" is unknown (reportAttributeAccessIssue)
1 error, 0 warnings, 0 informations

After — nothing left, and the script still writes the same fixture:

with this change

0 errors, 0 warnings, 0 informations