Hi Tor,
New definitions in rctdl_c_api.h.
/*! * Add a memory access callback function. The decoder will call the function for opcode addresses in the * address range supplied for the memory spaces covered. * * @param handle : Handle to decode tree. * @param st_address : Start address of memory area covered by the callback. * @param en_address : End address of the memory area covered by the callback. (inclusive) * @param mem_space : Memory space(s) covered by the callback. * @param p_cb_func : Callback function * * @return RCTDL_C_API rctdl_err_t : Library error code - RCDTL_OK if successful. */ RCTDL_C_API rctdl_err_t rctdl_dt_add_callback_mem_acc(const dcd_tree_handle_t handle, const rctdl_vaddr_t st_address, const rctdl_vaddr_t en_address, const rctdl_mem_space_acc_t mem_space, Fn_MemAcc_CB p_cb_func);
/*! * Remove a memory accessor by address and memory space. * * @param handle : Handle to decode tree. * @param st_address : Start address of memory accessor. * @param mem_space : Memory space(s) covered by the accessor. * * @return RCTDL_C_API rctdl_err_t : Library error code - RCDTL_OK if successful. */ RCTDL_C_API rctdl_err_t rctdl_dt_remove_mem_acc(const dcd_tree_handle_t handle, const rctdl_vaddr_t st_address, const rctdl_mem_space_acc_t mem_space);
Also in rctdl_if_types.h the definition of the callback fn. (here as it can be used in the C++ API as well. C++ API can also use a class interface).
/** * Callback function definition for callback memory accessor type. * * When using callback memory accessor, the decoder will call this function to obtain the * memory at teh address for the current opcodes. The memory space will represent the current * exception level and security context of the traced code. * * Return the number of bytes read, which can be less than the amount requested if this would take the * access address outside the range of addresses defined when this callback was registered with the decoder. * * Return 0 bytes if start address out of covered range, or memory space is not one of those defined as supported * when the callback was registered. * * @param address : start address of memory to be accessed * @param mem_space : memory space of accessed memory (current EL & security state) * @param reqBytes : number of bytes required * @param *byteBuffer : buffer for data. * * @return typedef uint32_t : Number of bytes actually read, or 0 for access error. */ typedef uint32_t (* Fn_MemAcc_CB)(const rctdl_vaddr_t address, const rctdl_mem_space_acc_t mem_space, const uint32_t reqBytes, uint8_t *byteBuffer);
These functions are now demonstrated and tested in simple_pkt_print_c_api when run with -decode -test_cb.
Regards
Mike
---------------------------------------------------------------- Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE ----------------------------------------------------------------
-----Original Message----- From: Jeremiassen, Tor [mailto:tor@ti.com] Sent: 08 December 2015 16:49 To: Mike Leach; coresight@lists.linaro.org Subject: RE: Trace Decoder Memory Accessor
Mike,
Looks good.
Tor
Tor Jeremiassen, Ph.D. Senior Member Technical Staff SDO Foundational Tools Texas Instruments Ph: 832 939 2356 13905 University Lane Fax: 832 939 2015 Sugar Land, TX 77479 Email: tor@ti.com
-----Original Message----- From: Mike Leach [mailto:Mike.Leach@arm.com] Sent: Tuesday, December 08, 2015 10:46 AM To: Jeremiassen, Tor; coresight@lists.linaro.org Subject: RE: Trace Decoder Memory Accessor
Hi Tor,
Looking at the C API it looks like the two alternatives for providing access to the image of the code that was traced is either through in-memory buffers or as binary files. I currently don't see a way to remove the accessors should the memory locations be "invalidated".
You are right, there isn't, it needs adding (to the C++ side too).
RCTDL_C_API rctdl_err_t rctdl_dt_remove_mem_acc(const dcd_tree_handle_t handle, const rctdl_vaddr_t start_address, const rctdl_mem_space_acc_t mem_space);
Would remove the accessor matching on address and memory space (accessors are not allowed to overlap so this should suffice).
Would it be possible to add the ability to remove accessors and also to add a third type of accessor, a pointer to a function that will access the requisite locations when called?
Yes - a function such as:-
RCTDL_C_API rctdl_err_t rctdl_dt_add_callback_mem_acc(const dcd_tree_handle_t handle, const rctdl_vaddr_t start_address, const rctdl_mem_space_acc_t mem_space, const uint32_t mem_length, const PMEMACCFN pFn);
with
PMEMACCFN defined as something like:-
typedef rctdl_err_t (* PMEMACCFN) ( const rctdl_vaddr_t address, const rctdl_mem_space_acc_t mem_space, uint32_t *num_bytes, uint8_t *p_buffer); would be sufficient?
Again would need adding to C++ side.
The memory accessor interface is quite immature at the moment. The only examples we are currently using are snapshots and thus fixed - no need to remove memory areas, and everything is files or buffers.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-----Original Message----- From: CoreSight [mailto:coresight-bounces@lists.linaro.org] On Behalf Of Jeremiassen, Tor Sent: 08 December 2015 16:19 To: coresight@lists.linaro.org Subject: Trace Decoder Memory Accessor
I think is this mostly a question for Mike, but I'll send it more broadly.
Looking at the C API it looks like the two alternatives for providing access to the image of the code that was traced is either through in-memory buffers or as binary files. I currently don't see a way to remove the accessors should the memory locations be "invalidated".
Would it be possible to add the ability to remove accessors and also to add a third type of accessor, a pointer to a function that will access the requisite locations when called?
Tor Jeremiassen, Ph.D. Senior Member Technical Staff SDO Foundational Tools Texas Instruments Ph: 832 939 2356 13905 University Lane Fax: 832 939 2015 Sugar Land, TX 77479 Email: tor@ti.com _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.