Inline API functions aren't directly accessible when wrapping the DLL with Python ctypes or similar. This includes some functions which set up xed_decode_inst_t before decode (xed_decoded_inst_set_input_chip etc.), and others which access fields after decode (xed_decoded_inst_get_length etc.). The libxed wrapper script in the Linux perf source tree has this:
# For now, assume the length is in byte 166
return inst.xedd[166], result
But depending on libxed build options, the offset sometimes isn't 166, so this breaks. If libxed exported out-of-line equivalents of all these functions then DLL wrappers wouldn't need to offset directly into the buffers.
It would also be useful to export (in the DLL sense) the sizes of key data types somehow. Referring to the Linux perf wrapper again, it has no idea how big a xed_decoded_inst_t is, it allocates 512 bytes to be on the safe side, but conceivably libxed could one day exceed this, leading to buffer overflow.
Inline API functions aren't directly accessible when wrapping the DLL with Python ctypes or similar. This includes some functions which set up xed_decode_inst_t before decode (xed_decoded_inst_set_input_chip etc.), and others which access fields after decode (xed_decoded_inst_get_length etc.). The libxed wrapper script in the Linux perf source tree has this:
But depending on libxed build options, the offset sometimes isn't 166, so this breaks. If libxed exported out-of-line equivalents of all these functions then DLL wrappers wouldn't need to offset directly into the buffers.
It would also be useful to export (in the DLL sense) the sizes of key data types somehow. Referring to the Linux perf wrapper again, it has no idea how big a xed_decoded_inst_t is, it allocates 512 bytes to be on the safe side, but conceivably libxed could one day exceed this, leading to buffer overflow.