On 19/10/2018 07:56, leo.yan@linaro.org wrote:
Hi Rob, Mathieu,
On Mon, Oct 08, 2018 at 12:16:02PM +0100, Robert Walker wrote:
This patch adds support for generating instruction samples from trace of AArch32 programs using the A32 and T32 instruction sets.
T32 has variable 2 or 4 byte instruction size, so the conversion between addresses and instruction counts requires extra information from the trace decoder, requiring version 0.9.4 of OpenCSD. A check for the new struct member has been added to the feature check for OpenCSD.
As I mentioned in another offline email, OpenCSD seems will have no version 0.9.4 and will directly jump to 0.1.0 version.
I used 0.9.4 as a temporary version as I didn't know what the next OpenCSD version would be. I'll change this to 0.10.0 when the patch is posted to the perf maintainers (after OpenCSD 0.10.0 is released).
I did several verifications with this patch and with Mike's OpenCSD patches [1]:
Tested with A64 binary, the decoding is same between with and without this patch; - Passed
Tested with A32/T32 instructions with static linkage; - Passed
Tested with A32/T32 instructions with dynamic linkage; For this case you could see below minor issue I observed:
--- Disassembly --- 00000440 printf@plt: 440: e28fc600 add ip, pc, #0, 12 444: e28cca10 add ip, ip, #16, 20 ; 0x10000 448: e5bcfbc8 ldr pc, [ip, #3016]! ; 0xbc8
--- Decoding --- main 8451 1 branches: f7c0e414 coresight_test1+0x2c (/root/coresight_test/libcstest.so) => 41159e main+0x12 (/root/coresight_test/main) main 8451 1 branches: 4115a8 main+0x1c (/root/coresight_test/main) => 411440 printf@plt+0x0 (/root/coresight_test/main) main 8451 1 branches: 411442 printf@plt+0x2 (/root/coresight_test/main) => f7b4e21c printf+0x0 (/usr/lib/arm-linux-gnueabihf/libc-2.27.so)
So you could see the decoding says it will jump to "411440 printf@plt+0x0", this is right if we connect with printf@plt disassembly code, but in the next decoding log it says the branch instruction is at "411442 printf@plt+0x2", this is not correct. We should expect the branch is taken at "448" rather than "442".
I also enclosed decoding and disassembly logs for your checking, please let me know if need me to provide more detailed info for testing case and testing commands for this.
[...]
I assume this is a simple printf("Hello world") program - I've been able to reproduce the same issue with a similar program (so the addresses are different):
Decode:
hello 3859 1 branches:u: 10428 __libc_csu_init+0x30 (/home/root/hello) => 103d4 main+0x0 (/home/root/ hello 3859 1 branches:u: 103e8 main+0x14 (/home/root/hello) => 102e4 printf@plt+0x0 (/home/root/hello hello 3859 1 branches:u: 102e6 printf@plt+0x2 (/home/root/hello) => 102d0 _init+0xc (/home/root/hello hello 3859 1 branches:u: 102dc _init+0x18 (/home/root/hello) => 0 [unknown] ([unknown])
Disassembly:
000102d0 printf@plt-0x14: 102d0: e52de004 push {lr} ; (str lr, [sp, #-4]!) 102d4: e59fe004 ldr lr, [pc, #4] ; 102e0 <_init+0x1c> 102d8: e08fe00e add lr, pc, lr 102dc: e5bef008 ldr pc, [lr, #8]! 102e0: 00010d20 .word 0x00010d20
000102e4 printf@plt: 102e4: e28fc600 add ip, pc, #0, 12 102e8: e28cca10 add ip, ip, #16, 20 ; 0x10000 102ec: e5bcfd20 ldr pc, [ip, #3360]! ; 0xd20
If I log the packets emitted from the OpenCSD decoder we get this:
CS_ETM_RANGE: [0xf747487c-0xf7474880] CS_ETM_RANGE: [0xf7474880-0xf74748aa] br CS_ETM_RANGE: [0x103d4-0x103ec] br <<---- entry to main() up to call to printf() CS_ETM_RANGE: [0x102e4-0x102e8] br <<---- execution of printf@plt here CS_ETM_RANGE: [0x102d0-0x102e0] br <<---- execution of printf@plt-0x14, jumping to actual printf CS_ETM_RANGE: [0xf7559be8-0xf7559c00] br CS_ETM_RANGE: [0xf7555024-0xf7555028]
So the reported samples match the output from the decoder: It would appear to have interpreted the instruction at 0x00102e4 as a branch. Either this is an error in the decoder, or it's some effect of the dynamic linking (the PLT wrapper functions may patched with the actual address of the printf function) - but I think the decode is based on the unpatched code from the image files.
Regards
Rob