DynamoRIO / DynamoRIO/dynamorio
drwrap fails to identify some malloc() calls
- Dominant language
- C
- Stars
- 3.2k
- Forks
- 629
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 31
Description
In Linux systems with GLIBC 2.40 `drwrap` fails to identify a malloc call in the `common.eflags` and `common.nzcv` binaries.
To reproduce, use `libcallstack` as follows.
On x86_64:
```
${DR_BUILD_DIR}/bin64/drrun -s 90 -quiet -debug -killpg -stderr_mask 0xC -dumpcore_mask 0 -code_api -c ${DR_BUILD_DIR}/api/samples/../bin/libcallstack.so -- ${DR_BUILD_DIR}/suite/tests/bin/common.eflags
```
On AARCH64:
```
${DR_BUILD_DIR}/bin64/drrun -s 90 -quiet -debug -killpg -stderr_mask 0xC -dumpcore_mask 0 -code_api -c ${DR_BUILD_DIR}/api/samples/../bin/libcallstack.so -- ${DR_BUILD_DIR}/suite/tests/bin/common.nzcv
```
The output should contain something like:
```
wrapping /usr/lib/x86_64-linux-gnu/libc.so.6!malloc
malloc called from:
libc.so.6!__GI___libc_malloc
libc.so.6!__libc_start_call_main
libc.so.6!__libc_start_main_alias_2
common.call_to_malloc!
[...] <--- the rest of the program output
```
To double check common.eflags (or common.nzcv) actually have a call to malloc, run the binaries under gdb and break on malloc.
Using ltrace has been unreliable (i.e., gdb breaks on malloc, but ltrace does not find it):
```
ltrace -e malloc ${path_to_build_dir}/suite/tests/bin/common.[eflags | nzcv]
```
Contributor guide
Assessment
This issue has not been assessed yet.