Closed Bug 594397 Opened 14 years ago Closed 6 years ago

Write a dehydra script that validates CallInfo corectness.

Categories

(Tamarin Graveyard :: Baseline JIT (CodegenLIR), defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: edwsmith, Unassigned)

References

Details

Sketch:

In jit-calls.h, each FUNCTION, METHOD (etc) macro expands to a static const CallInfo declaration, containing a cast to a C++ function.  The fields of this struct are visible to dehydra (i think), and so we should be able to get the type object for each function pointer.  

Given the function type and the constant values of the CallInfo struct, we can:

1. Ensure the number and types of each argument are correct.  The script can unpack the argument mask and check it against the dehydra-exposed argument types of the target function.

2. Ensure the ABI is correct; if the target function is a plain function, static method, instance method, or virtual method, dehydra can see it.  furthermore, i think it can detect the GCC __fastcall attribute, for x86.

3. If something is wrong, the script could compute + print the correct values as part of the error message.
Blocks: 583074
Given a list of C++ functions we call from JIT code, the analyzer could also Generate a C++ compiler function that generates LIR to call that underlying C++ function.  The compiler stub could typecheck each incoming LIR argument for type-correctness, and the api of the stub could make it impossible to pass the wrong number of LIns* parameters.

When we're ready to generate code instead of just analyzing code, we can generate correctly typed CallInfo instances, instead of using macrology to declare them.
Flags: flashplayer-qrb+
Summary: We could write a dehydra script that validates CallInfo corectness. → Write a dehydra script that validates CallInfo corectness.
Target Milestone: --- → Future
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.