[llvm-dev] Custom Alloca implementation

Tue Jan 28 07:31:59 PST 2020

This is not really my area, but I am curious whether the memory safety you are seeking would be addressed by some combination of the Stack Protector pass and the Memory Sanitizer.
If you do wish a separate solution, note that (IIUC) `alloca` does not necessarily lower to a specific machine instruction.  For one thing, scalar variables will typically be optimized into registers, and will not have a memory location at all.  Local variables that are assigned to memory locations will be allocated a “stack slot” in the stack frame; this frame would be allocated in the function prologue.  I am not sure where stack slots are assigned, but you could probably make the slots larger when they are assigned.
HTH,
--paulr

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Udit agarwal via llvm-dev
Sent: Monday, January 27, 2020 11:18 PM
To: Alberto Barbaro <barbaro.alberto at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Custom Alloca implementation

---- CC'ing llvm-dev list ----

On Tue, Jan 28, 2020 at 9:46 AM Udit agarwal <dev.madaari at gmail.com<mailto:dev.madaari at gmail.com>> wrote:
Hi Alberto,

On Mon, Jan 27, 2020 at 7:42 PM Alberto Barbaro <barbaro.alberto at gmail.com<mailto:barbaro.alberto at gmail.com>> wrote:
Hi Udit,
No problem at all. When you say at runtime you mean using the Interpreter class or something else?
No, I want to access this information at runtime, when the binary(obtained from compiling this LLVM IR) is executed on the host machine. For example, if along with every Alloca I'm allocating an additional 4 bytes to store the object bounds, then I can put runtime checks to ensure spatial memory safety in few cases(like out of bounds memory access, or buffer overflow). In order to do so, I need to allocate an extra 4 bytes along with every Alloca - hence my original question - At what location in Alloca implementation, should I make this change? Probably, I should make this change at the location where Alloca is lowered to Machine specific instruction.

Regards,
Udit Agarwal

If I understood properly your problem I think you could do some getDataLayout.getTypeAllocSize(I->getOperand(0)->getType());

Where is I is the reference to the Alloca instruction.

I hope it is correct :)

Alberto

On Mon, Jan 27, 2020, 13:40 Udit agarwal <dev.madaari at gmail.com<mailto:dev.madaari at gmail.com>> wrote:
---Adding llvm-dev list to CC---
Hi Alberto,

Thanks for your prompt reply. Actually, I need this information(about total allocation size and object structure) on runtime, so that is why I was planning to encode this info and store it in the memory itself.

Regards,
Udit

On Mon, Jan 27, 2020 at 7:05 PM Alberto Barbaro <barbaro.alberto at gmail.com<mailto:barbaro.alberto at gmail.com>> wrote:
Hello Udit,
I'm not sure but can't you achieve the same just using metadata avoiding to change the alloca instruction?

Thanks
Alberto

On Mon, Jan 27, 2020, 12:09 Udit agarwal via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hello all,

In my project, I need to allocate an extra 4 Bytes in every Alloca instruction. These additional bytes will be used to store the 'allocation info'(like size and structure of the allocated object etc). Instead of adding 4 bytes to the Alloca 'size' operand at every Alloca Instruction, I was thinking to make this change at the level where Alloca gets converted to machine IR.
Can anyone please point me towards the code which actually handles this conversion(lowering of Alloca Inst)?
--
Regards,
Udit kumar agarwal
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

--
Regards,
Udit kumar agarwal
http://uditagarwal.in/

--
Regards,
Udit kumar agarwal
http://uditagarwal.in/

--
Regards,
Udit kumar agarwal
http://uditagarwal.in/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200128/5e3c41ed/attachment.html>