Bug 1969984

Reproduced also with gcc-toolset-11-dyninst-11.0.0-1.el8.aarch64:

+++ This bug was initially created as a clone of Bug #1965501 +++

The dsyninst smoke test failed on aarch64 for dyninst-11.0.0-1.el8.aarch64 in the static instrumentation phase. Testcase:

http://pkgs.devel.redhat.com/cgit/tests/dyninst/tree/Sanity/smoke-test


Test log:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Testing static instrumentation
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

[ ... stuff deleted ... ] 

./mutated: symbol lookup error: ./mutated: undefined symbol: _Z4incrv

--- Additional comment from Stan Cox on 2021-06-04 21:52:21 CEST ---

The routine mutatee has an internal function incr, which has no callers, that the mutator adds a call to.  So the mutated executable ends up with:
Relocation section [31] '.rela.dyn' at offset 0x305d0 contains 7 entries:
   ...
   0x0000000000500070  AARCH64_JUMP_SLOT 000000000000000000      +0 _Z4incrv
Symbol table [27] '.dynsym' contains 18 entries:
   ...
   17: 0000000000000000     36 FUNC    GLOBAL DEFAULT    UNDEF _Z4incrv
Symbol table [41] '.symtab' contains 161 entries:
  ...
  145: 0000000000400894     36 FUNC    GLOBAL DEFAULT       13 _Z4incrv

So _Z4incrv (incr) is in the symbol table but also erroneously appears in the dynamic symbol table

Just as a double check, converting the test so that incr is defined in a shared object works as expected (attached)

So the problem is when dyninst creates a call to a static function when in static mode (stapdyn uses dynamic mode).  The dyninst testsuite, as far as I can tell, does not seem to test this.

--- Additional comment from Stan Cox on 2021-06-04 22:01:28 CEST ---



--- Additional comment from Stan Cox on 2021-06-04 22:18:35 CEST ---

Corresponding upstream bug:
 https://github.com/dyninst/dyninst/issues/1045