Provide out-of-line equivalents of inline functions

[algr]

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.

[marjevan]

Hello,

In the upcoming release, XED will introduce a special build option that exports wrapper functions. This will address the challenge of accessing inlined API functions (such as xed_decoded_inst_set_input_chip, xed_decoded_inst_get_length, etc.) when building XED as a shared object.

I will also provide examples demonstrating how to load and interact with the XED shared library using Python. Please note that this initial support primarily focuses on resolving the exposure of inlined APIs. Any provided Python bindings will be partial, mainly for the example's demonstration purposes.

Once the release is out, I’d greatly appreciate feedback from the community on this new capability, as I’m eager to see how developers will leverage XED APIs with Python workloads.