Calling c++ functions returning non-pod types

Calling c++ functions returning non-pod types

[Philip Ashmore]

Hi there.

I recently had the need to call a function that returns a c++ string.
It didn't work as std::string has constructors, destructors, assignment 
operators...

I eventually found the relevant documentation on this

http://mentorembedded.github.com/cxx-abi/abi.html#calls

which states that for such return types a hidden pointer to a temporary 
is needed.

I got it to work by lying about the function. Instead of

    string run_cmd(const char * cmd)

I told libffi that the function looked like

    void run_cmd(string * ret, const char * cmd)

and passed in a pointer to a string to assign the result to as the first 
argument.

You should know that I described the string instance as a pointer:

     string rc;
     string * rc_addr = & rc;

     ffi_type *args[2];
     args[0] = &ffi_type_pointer;
     args[1] = &ffi_type_pointer;

     void *values[2];
     values[0] = &rc_addr;
     values[1] = &s;

I think a better option would be to tell libffi that the return type is 
a "non-pod" and let it jump the hoops appropriate for the architecture - 
am I correct in guessing that my approach isn't portable?

Regards,
Philip Ashmore

Re: Calling c++ functions returning non-pod types

[Andrew Haley]

On 02/21/2013 01:29 PM, Philip Ashmore wrote:
> I think a better option would be to tell libffi that the return type is 
> a "non-pod" and let it jump the hoops appropriate for the architecture - 
> am I correct in guessing that my approach isn't portable?

Sort of.  There is a standardish C++ ABI known for reasons too arcane to
go into as the Itanium C++ ABI
http://refspecs.linux-foundation.org/cxxabi-1.83.html

However, putting all this stuff into libffi would be too much IMO.  You
could think of defining a C++ layer that calls libffi.

Andrew.

Re: Calling c++ functions returning non-pod types

[Philip Ashmore]

On 21/02/13 15:19, Andrew Haley wrote:
> On 02/21/2013 01:29 PM, Philip Ashmore wrote:
>> I think a better option would be to tell libffi that the return type is
>> a "non-pod" and let it jump the hoops appropriate for the architecture -
>> am I correct in guessing that my approach isn't portable?
>
> Sort of.  There is a standardish C++ ABI known for reasons too arcane to
> go into as the Itanium C++ ABI
> http://refspecs.linux-foundation.org/cxxabi-1.83.html
>
> However, putting all this stuff into libffi would be too much IMO.  You
> could think of defining a C++ layer that calls libffi.
if only because libffi doesn't create temporaries for ignored return values.
I guess I'm going to have to define a portability layer myself then.

Does/could libffi define macro I could use to determine the c++ ABI?

The next thing I'd need is a page of docs for all the c++ ABIs for the c 
ABIs that libffi supports.
>
>
> Andrew.
>
>
If you could reply with such a list that would be great - I'll push 
ahead with the platform I'm on now - Debian sid amd64.

Philip

Re: Calling c++ functions returning non-pod types

[Andrew Haley]

On 02/21/2013 05:46 PM, Philip Ashmore wrote:
> On 21/02/13 15:19, Andrew Haley wrote:
>> On 02/21/2013 01:29 PM, Philip Ashmore wrote:
>>> I think a better option would be to tell libffi that the return type is
>>> a "non-pod" and let it jump the hoops appropriate for the architecture -
>>> am I correct in guessing that my approach isn't portable?
>>
>> Sort of.  There is a standardish C++ ABI known for reasons too arcane to
>> go into as the Itanium C++ ABI
>> http://refspecs.linux-foundation.org/cxxabi-1.83.html
>>
>> However, putting all this stuff into libffi would be too much IMO.  You
>> could think of defining a C++ layer that calls libffi.
>
> if only because libffi doesn't create temporaries for ignored return values.
> I guess I'm going to have to define a portability layer myself then.
> 
> Does/could libffi define macro I could use to determine the c++ ABI?

Only the usual system defines.

> The next thing I'd need is a page of docs for all the c++ ABIs for the c 
> ABIs that libffi supports.
>
> If you could reply with such a list that would be great - I'll push 
> ahead with the platform I'm on now - Debian sid amd64.

All the Linuxen use the Itanium C++ ABI.  Do you care about Windows
and BSD?

Andrew.

Re: Calling c++ functions returning non-pod types

[Andrew Haley]

On 02/21/2013 05:51 PM, Andrew Haley wrote:
> All the Linuxen use the Itanium C++ ABI.

Oh, except ARM, but I think it's the same for what you need.

Andrew.

Re: Calling c++ functions returning non-pod types

[Philip Ashmore]

On 21/02/13 17:51, Andrew Haley wrote:
> On 02/21/2013 05:46 PM, Philip Ashmore wrote:
>> On 21/02/13 15:19, Andrew Haley wrote:
>>> On 02/21/2013 01:29 PM, Philip Ashmore wrote:
>>>> I think a better option would be to tell libffi that the return type is
>>>> a "non-pod" and let it jump the hoops appropriate for the architecture -
>>>> am I correct in guessing that my approach isn't portable?
>>>
>>> Sort of.  There is a standardish C++ ABI known for reasons too arcane to
>>> go into as the Itanium C++ ABI
>>> http://refspecs.linux-foundation.org/cxxabi-1.83.html
>>>
>>> However, putting all this stuff into libffi would be too much IMO.  You
>>> could think of defining a C++ layer that calls libffi.
>>
>> if only because libffi doesn't create temporaries for ignored return values.
>> I guess I'm going to have to define a portability layer myself then.
>>
>> Does/could libffi define macro I could use to determine the c++ ABI?
>
> Only the usual system defines.
>
>> The next thing I'd need is a page of docs for all the c++ ABIs for the c
>> ABIs that libffi supports.
>>
>> If you could reply with such a list that would be great - I'll push
>> ahead with the platform I'm on now - Debian sid amd64.
>
> All the Linuxen use the Itanium C++ ABI.  Do you care about Windows
> and BSD?
I don't know BSD and my projects won't run on Windows because of design 
choices, although I'd be happy if someone wanted to port my stuff onto 
them - I could merge the changes back in.

I'd like it if at some point my projects could run on all the platforms 
libffi supports, but that's some ways off.
>
>
> Andrew.
>
Philip