On Thu, Mar 16, 2017 at 11:24 AM, Dibyendu Majumdar
<mobile@xxxxxxxxxxxxxxx> wrote:
>
> Agreed and we are doing that except that the function call instruction
> only has the type of the call, not the arguments (as far as I
> understand - apologies if I have got this wrong).
The "OP_CALL" should have the call type in the instruction itself:
struct /* call */ {
pseudo_t func;
struct pseudo_list *arguments;
struct symbol *fntype;
};
in that "fntype".
So you should not need it for the pseudo (that contains the address of
the function to call).
That was done exactly for the varargs issue, see commit ff527e2
("sparse, llvm: Make function declaration accessible to backend")
Now, that code may be *buggy*, of course, but it's actually very
important, exactly for the same kind of "one pseudo may be associated
with multiple types".
In particular, it's not uncommon to have auto-generated code (or
various handwritten interpreters) have the function be encoded as some
kind of void pointer, and then depending on use, the same pointer
value is used differently.
Eg code like this:
typedef int (*binop_t)(int, int);
typedef int (*unop_t)(int);
#define BINOP 0
unsigned int execute(int type, void *fn, int arg1, int arg2)
{
if (type == BINOP)
return ((binop_t)fn)(arg1,arg2);
return ((unop_t)fn)(arg1);
}
which will linearize to something that does:
call.32 %r7 <- %r6, %arg3, %arg4
in one branch, and
call.32 %r13 <- %r6, %arg3
in another. Notice how it uses the same pseudo (%r6) in both cases,
even though the type of the function called is different.
So like all the other cases, the type of the operation (in this case,
a function call) has to be encoded in the instruction itself, not in
the pseudo.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
