Re: return value buffer malloc()'ed vs alloca()'ed

[Andrew Haley <aph at redhat dot com>]

On 10/08/2013 06:13 PM, Igor Bogomazov wrote:
> Hello,
> 
> I've been trying to investigate valgrind warnings for a while and found
> an undocumented feature, please let me know if it is well-known.
> 
> What I did.
> 
> I modified a code given in Â2.2 Simple Example so that return value
> (rc), originally declared as (int), became an (int *)malloc(sizeof(int))
> so that it is resident in heap since that. Of cource, (&rc) replaced
> with (rc) later in the code.
> 
> What I get.
> 
> valgrind complaints about ÂInvalid write of size 8Â while ÂAddress
> 0x55ec040 is 0 bytes inside a block of size 4 alloc'dÂ, it is exactly
> that allocated (rc) buffer.
> 
> Notes.
> 
> Allocating buffer for the return value using alloca() does the trick and
> makes valgrind silent.
> 
> Further.
> 
> I looked at x86/unix64.S, it is exactly the line:
> movq	%rax, (%rdi)
> that causes the valgrind's warning (at .Lst_uint32)
> 
> That is my question: is it necessary to allocate a buffer for the return
> value with alloca() and never with malloc()?

As far as I can see, libffi always writes a whole word into the rvalue:

.Lst_uint8:
	movzbq	%al, %rax
	movq	%rax, (%rdi)
	ret
	.align 2
.Lst_sint8:
	movsbq	%al, %rax
	movq	%rax, (%rdi)
	ret
	.align 2
.Lst_uint16:
	movzwq	%ax, %rax
	movq	%rax, (%rdi)
	.align 2
        ...

This looks quite deliberate, but it is rather different from what the
documentation specifies:

     RVALUE is a pointer to a chunk of memory that will hold the result
     of the function call.  This must be large enough to hold the
     result and must be suitably aligned; it is the caller's
     responsibility to ensure this

So it's definitely a bug, but I don't know whether it's a bug in libffi or
in its documentation.

Andrew.