HI,
Looks like the ETMv4 decoder is not tracking the ISA change as Al says. This will need a mod and I'll need to generate a test case unless the raw trace and images can be supplied from any of the above tests.
Mike On Sat, 20 Oct 2018 at 08:43, leo.yan@linaro.org wrote:
On Fri, Oct 19, 2018 at 10:10:49AM +0000, Al Grant wrote:
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 toprintf() 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
I don't familiar with PLT and GOT, after took a bit time to google related info and I think we should assume PLT code will not be changed and GOT will be updated for dynamic link, right?
If so this means the PLT code will be not patched with other instructions on the fly. Just curious if I miss something for this.
the decode is based on the unpatched code from the image files.
It looks like it might not have spotted that this is a T32 BLX to A32 code in the PLT, and is decoding
102e4: e28fc600 add ip, pc, #0, 12as if it was T32. This decodes to a random 16-bit STM (0xc600) at 102e4, followed by a random 16-bit direct branch (0xe28f) at 102e6. The decoder tells you that 102e6 is the branch origin:
hello 3859 1 branches:u: 102e6printf@plt+0x2 (/home/root/hello) => 102d0 _init+0xc (/home/root/hello
and ends the ETM range at 102e8:
CS_ETM_RANGE: [0x102e4-0x102e8] br <<---- execution of printf@plthere
The LDR PC (in the actual PLT code) will emit an ETM branch address packet which gets the decoder back on track. It just gets the wrong waypoint address for the origin of the branch.
A32/T32 state changes that can be statically inferred from the instructions (e.g. BLX) aren't specially indicated in the ETM packets, you just get an E atom. The decoder has to deduce the state change from the code.
If the decoding misses to change state from T32 to A32, should we expect an updated decoding in OpenCSD for related fixing?
Thanks, Leo Yan _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight