* Calling c++ functions returning non-pod types
@ 2013-02-21 13:31 Philip Ashmore
2013-02-21 15:19 ` Andrew Haley
0 siblings, 1 reply; 6+ messages in thread
From: Philip Ashmore @ 2013-02-21 13:31 UTC (permalink / raw)
To: libffi-discuss
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Calling c++ functions returning non-pod types
2013-02-21 13:31 Calling c++ functions returning non-pod types Philip Ashmore
@ 2013-02-21 15:19 ` Andrew Haley
2013-02-21 17:48 ` Philip Ashmore
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Haley @ 2013-02-21 15:19 UTC (permalink / raw)
To: Philip Ashmore; +Cc: libffi-discuss
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Calling c++ functions returning non-pod types
2013-02-21 15:19 ` Andrew Haley
@ 2013-02-21 17:48 ` Philip Ashmore
2013-02-21 17:51 ` Andrew Haley
0 siblings, 1 reply; 6+ messages in thread
From: Philip Ashmore @ 2013-02-21 17:48 UTC (permalink / raw)
To: libffi-discuss
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Calling c++ functions returning non-pod types
2013-02-21 17:48 ` Philip Ashmore
@ 2013-02-21 17:51 ` Andrew Haley
2013-02-21 17:53 ` Andrew Haley
2013-02-21 17:57 ` Philip Ashmore
0 siblings, 2 replies; 6+ messages in thread
From: Andrew Haley @ 2013-02-21 17:51 UTC (permalink / raw)
To: Philip Ashmore; +Cc: libffi-discuss
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Calling c++ functions returning non-pod types
2013-02-21 17:51 ` Andrew Haley
@ 2013-02-21 17:53 ` Andrew Haley
2013-02-21 17:57 ` Philip Ashmore
1 sibling, 0 replies; 6+ messages in thread
From: Andrew Haley @ 2013-02-21 17:53 UTC (permalink / raw)
To: Philip Ashmore; +Cc: libffi-discuss
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Calling c++ functions returning non-pod types
2013-02-21 17:51 ` Andrew Haley
2013-02-21 17:53 ` Andrew Haley
@ 2013-02-21 17:57 ` Philip Ashmore
1 sibling, 0 replies; 6+ messages in thread
From: Philip Ashmore @ 2013-02-21 17:57 UTC (permalink / raw)
To: Andrew Haley; +Cc: libffi-discuss
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-02-21 17:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-21 13:31 Calling c++ functions returning non-pod types Philip Ashmore
2013-02-21 15:19 ` Andrew Haley
2013-02-21 17:48 ` Philip Ashmore
2013-02-21 17:51 ` Andrew Haley
2013-02-21 17:53 ` Andrew Haley
2013-02-21 17:57 ` Philip Ashmore
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).