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

[Leo Yan]

Hi Namhyung,

On 10/8/2024 10:00 PM, Namhyung Kim wrote:

[...]

> On Tue, Oct 08, 2024 at 11:24:45AM -0700, Steve Clevenger wrote:
>>
>> 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.
> 
> Oh, is it applied to the coresight tree already?

No.

> I don't think I got> any notification for that.  Please make sure to notify
perf maintainers
> (and hopefullly to get Ack's) when you touch non-coresight part of the
> code.
> 
> Also I think we need to clarify how to route coresight tool patches.  I
> thought they are going through the perf-tools tree.  But it doesn't seem
> to be the case?

AFAIK, in most cases, Arm patches for the perf will be picked up via
perf-tools tree, including this patch series.

[...]
>> 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.
> 
> Ok, thanks for sharing this.  I'm ok with exposing pgoff to the python
> script itself.  But I'd like to make sure if it works correctly with
> PIEs that have non-zero page offsets in other places (probably ok).

Fair point. The 'pgoff' is exposed from the kernel's VMA info, it is a runtime
value after the DSO loading. After set the MAPPING_TYPE__IDENTITY type for PIE
DSO, the 'pgoff' will be ignored in both the perf tool (see map__map_ip()) and
the script.

Sorry that I missed this part when reviewed the change. I understood Steve
have verified the script result. Seems to me, the critical question is kernel
has an offset for PIE DSO but why ignore it in the tool.

@Steve, if you have more info, could you explain a bit what is the reason for
ignoring pgoff for PIE DSO?

Thanks,
Leo