[PATCH V8 0/4] arm-cs-trace-disasm.py/perf must accommodate non-zero DSO text offset

Tue Oct 8 11:24:45 PDT 2024

Hello Namhyung,

Sorry your question is so late. I don't include the ELF headers here,
but the problem can be seen with a perf.data packet dump of user
instruction trace capture. The problem is with the non-zero pgoff. The
arm-cs-trace-disasm.py script was never passed pgoff information to
adjust the start/end disassemble range passed to objdump. This patch
distributes the fix between perf and the arm-cs-trace-disasm.py script.

Here's a brief excerpt from an e-mail I sent to James Clark describing
the patch before I submitted it.

Regards,
Steve C.

-----------------------------------------------------------------
.
.
This e-mail is to document what I know and don’t know about the problem.
The background is Fedora 38 introduced non-zero text offsets into common
shared objects and executables (e.g. libc.so.6, etc.).

If you were to ‘perf report --dump’ the perf.data of a user mode
instruction trace on Fedora 37 and grep the PERF_RECORD_MMAP2 packets
you’ll notice all zero values (@ 0) for shared binary and executable
text offsets. Repeat the same for user trace collected on Fedora 38/39,
and these text offsets show as non-zero.

Fedora 37:

4294967295 18446744073709551615 0x8ac8 [0x78]: PERF_RECORD_MMAP2
2389577/2389577: [0xffff85124000(0x42000) @ 0 103:04 805306555
1941233998]: r-xp /usr/lib/ld-linux-aarch64.so.1
4294967295 18446744073709551615 0x8b40 [0x60]: PERF_RECORD_MMAP2
2389577/2389577: [0xffff85161000(0x1000) @ 0 00:00 0 0]: r-xp [vdso]
4294967295 18446744073709551615 0x8ba0 [0x68]: PERF_RECORD_MMAP2
2389577/2389577: [0xaaaab09b0000(0x10000) @ 0 103:04 1140851919
994218038]: r-xp /usr/bin/dd
4294967295 18446744073709551615 0x8c08 [0x70]: PERF_RECORD_MMAP2
2389577/2389577: [0xffff84f70000(0x1a9000) @ 0 103:04 1677721733
3891973508]: r-xp /usr/lib64/libc.so.6

Fedora 39:

4294967295 18446744073709551615 0x8ac8 [0x78]: PERF_RECORD_MMAP2
18229/18229: [0xffffa5512000(0x1d000) @ 0x10000 103:04 161 4093340249]:
r-xp /usr/lib/ld-linux-aarch64.so.1
4294967295 18446744073709551615 0x8b40 [0x60]: PERF_RECORD_MMAP2
18229/18229: [0xffffa554f000(0x1000) @ 0 00:00 0 0]: r-xp [vdso]
4294967295 18446744073709551615 0x8ba0 [0x68]: PERF_RECORD_MMAP2
18229/18229: [0xaaaade7e0000(0xb000) @ 0x10000 103:04 536876423
421616320]: r-xp /usr/bin/dd
4294967295 18446744073709551615 0x8c08 [0x70]: PERF_RECORD_MMAP2
18229/18229: [0xffffa5360000(0x11f000) @ 0x30000 103:04 536873199
2415801053]: r-xp /usr/lib64/libc.so.6

The arm-cs-trace-disasm.py script never gets to see the text offset into
the dso binaries, so has no opportunity to adjust the start/end address
range passed to objdump. This wasn’t a problem on Fedora 37 and below
since there’s no start/end adjustment for a zero text offset. On Fedora
38/39 distros, the instruction trace shows unconditional branch
instructions which do not branch to the target address, the clearest
indication of trouble.
-----------------------------------------------------------------

On 10/7/2024 10:51 PM, Namhyung Kim wrote:
> Hello,
> 
> Sorry for the long delay.  But can you please explain your problem in
> more detail?  Showing ELF program (or section) header would be helpful
> as well.
> 
> Is the problem when the text mapping has non-zero pgoff only?  Is the
> kernel symbols working correctly?  Or is it just the Python script
> broken?
> 
> Thanks,
> Namhyung
> 
> On Mon, Sep 09, 2024 at 03:30:02PM -0600, Steve Clevenger wrote:
>> Changes in V8:
>>   - in arm-cs-trace-disasm.py, ensure map_pgoff is not converted to
>>     string.
>>   - Remove map_pgoff integer conversion in dso not found print
>>     message.
>>
>> Changes in V7:
>>   - In arm-cs-trace-disasm.py, fix print message core dump resulting
>>     from mixed type arithmetic.
>>   - Modify CS_ETM_TRACE_ON filter to filter zero start_addr. The
>>     CS_ETM_TRACE_ON message is changed to print only in verbose mode.
>>   - Removed verbose mode only notification for start_addr/stop_addr
>>     outside of dso address range.
>>
>> Changes in V6:
>>   - In arm-cs-trace-disasm.py, zero map_pgoff for kernel files. Add
>>     map_pgoff to start/end address for dso not found message.
>>   - Added "Reviewed-by" trailer for patches 1-3 previously reviewed
>>     by Leo Yan in V4 and V5.
>>
>> Changes in V5:
>>   - In symbol-elf.c, branch to exit_close label if open file.
>>   - In trace_event_python.c, correct indentation. set_sym_in_dict
>>     call parameter "map_pgoff" renamed as "addr_map_pgoff" to
>>     match local naming.
>>
>> Changes in V4:
>>   - In trace-event-python.c, fixed perf-tools-next merge problem.
>>
>> Changes in V3:
>>   - Rebased to linux-perf-tools branch.
>>   - Squash symbol-elf.c and symbol.h into same commit.
>>   - In map.c, merge dso__is_pie() call into existing if statement.
>>   - In arm-cs-trace-disasm.py, remove debug artifacts.
>>
>> Changes in V2:
>>   - In dso__is_pie() (symbol-elf.c), Decrease indentation, add null pointer
>>     checks per Leo Yan review.
>>   - Updated mailing list distribution.
>>
>> Steve Clevenger (4):
>>   Add dso__is_pie call to identify ELF PIE
>>   Force MAPPING_TYPE__IDENTIY for PIE
>>   Add map pgoff to python dictionary based on MAPPING_TYPE
>>   Adjust objdump start/end range per map pgoff parameter
>>
>>  .../scripts/python/arm-cs-trace-disasm.py     | 17 ++++--
>>  tools/perf/util/map.c                         |  4 +-
>>  .../scripting-engines/trace-event-python.c    | 13 +++-
>>  tools/perf/util/symbol-elf.c                  | 61 +++++++++++++++++++
>>  tools/perf/util/symbol.h                      |  1 +
>>  5 files changed, 86 insertions(+), 10 deletions(-)
>>
>> -- 
>> 2.44.0
>>