[Lldb-commits] [PATCH] D33035: Tool for using Intel(R) Processor Trace hardware feature

[Abhishek via Phabricator via lldb-commits]

abhishek.aggarwal added a comment.

In https://reviews.llvm.org/D33035#816337, @clayborg wrote:

> I am not sure how sensitive typemaps are to the names of the arguments? Maybe we can just have you use different names and then the two typemaps won't collide? You can also write some manual code to do the remapping without typemaps.
>
> Regardless of whether you are going to change the API or not, you will need to write something to make it work in python.
>
>   const uint8_t * ptdecoder_private:: Instruction::GetRawBytes() const;
>
>
> What does swig do right now when the above code is converted to python? It needs to make a python string from this and the GetRawBytesSize()...


Hi Greg .. You are right. I checked the swig converted code for this API and it was not using GetRawBytesSize(). I have changed the C++ API signature as you had suggested and wrote a new typemap to handle it. It is mostly similar to the one defined in lldb typemaps but doesn't use internal lldb implementation of PythonBytes. Let me know if something is not right. I am submitting new patch set. Thanks a lot for your feedback :)

In https://reviews.llvm.org/D33035#816337, @clayborg wrote:

> I am not sure how sensitive typemaps are to the names of the arguments? Maybe we can just have you use different names and then the two typemaps won't collide? You can also write some manual code to do the remapping without typemaps.
>
> Regardless of whether you are going to change the API or not, you will need to write something to make it work in python.
>
>   const uint8_t * ptdecoder_private:: Instruction::GetRawBytes() const;
>
>
> What does swig do right now when the above code is converted to python? It needs to make a python string from this and the GetRawBytesSize()...





https://reviews.llvm.org/D33035