[LLVMdev] Controlling the stack layout

[Nicolas Geoffray]

Hi Nick,

Nick Johnson wrote:
>> I'd like to generate this layout:
>>
>> 12(%ebp)    - second function parameter
>> 8(%ebp)      - first function parameter
>> 4(%ebp)      - old %EIP (the function's "return address")
>> 0(%ebp)      - old %EBP (previous function's base pointer)
>> -4(%ebp)     - My language specific information
>> -8(%ebp)     - first local variable
>> -12(%ebp)   - second local variable
>>
>>     
>
> Take a look at the register allocators, each of which is implemented
> as a MachineFunctionPass.  These are responsible for assigning stack
> slots, and it shouldn't be too hard to modify them to reserve some
> stack slots.
>
>   

Thanks, but I don't want to modify the register allocators. I'd like to 
write an llvm-external machine pass.

> Also, I'd recommend that you consider the prevalence of this language
> specific information, and re-evaluate whether you want to modify the
> stack frame at all. 

Yes, I do :) There are some alternatives, but this looks like the most 
efficient. What I'm facing is engineering issues, since adding a new 
information in the stack frame is similar to adding the frame-pointer 
information.

>  Do you expect *every* function will need it, or
> *at most* every function will need it?  

Every function that I compile with llvm.

> Could this information also be
> encoded into a per-function local variable?  

No, because then you wouldn't know where the information is stored when 
walking the stack.

> Could your compiler
> generate code to maintain a separate stack for such information?
>
>   

Sure, but it's much more expensive than a simple push and pop.

> Also, out of curiosity: are you working on something like Java
> security contexts?  Or perhaps something like ProPolice canary values?
>
>   

I'm working on VMKit, which implements a JVM on top of LLVM. And an easy 
way to walk the stack is to have a methodID stored in each stack frame 
to locate which method the frame belongs to.

Nicolas