llvm dev - Sep 2018 - Added AllocaInsts are relocated in stack

Hi Tim,

Thanks for your reply. However, I have seen that addressSanitizer has done
this by placing redzones around each local variable. But i have not figured
out yet how they have done it, I was wondering if there is a switch or a
method by which I can reset the slotNumbering given to each instruction. By
doing so, LLVM would place them in the expected order I guess.

Best regards,
Saman

On Fri, Sep 21, 2018 at 5:29 AM Tim Northover <t.p.northover at gmail.com>
wrote:
> On Thu, 20 Sep 2018 at 21:38, sam djafari via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I am wondering how I can prevent LLVM from doing re-ordering them, or
> even reset the AllocaInst numbers, so the newly added AllocaInst can be
> inserted between the existing and original local variables?
>
> As far as I know you can't. LLVM makes no guarantees about stack
> layout at any point.
>
> What you almost certainly need to do is replace the original alloca
> with one big enough to contain both the data and the metadata. You can
> use ReplaceAllUsesWith directly on the new alloca for the existing
> uses, and then your metadata handling would GEP into it before access
> to get to the right part.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180921/4ed04e58/attachment.html>

Hi Sam,

On Fri, 21 Sep 2018 at 14:05, sam djafari <sami.djafari at gmail.com>
wrote:
> Thanks for your reply. However, I have seen that addressSanitizer has done
this by placing redzones around each local variable.
Maybe conceptually, but as far as I can see from the IR ASAN maintains
a completely separate stack via calls to runtime support (like
__asan_stack_malloc).
> By doing so, LLVM would place them in the expected order I guess.
I doubt it. Allocating objects on the stack involves a reasonably
sophisticated algorithm to try and minimize space consumed. Some of
that involves reordering variables with different sizes so that
they're contiguous. Some involves lifetime tracking to try and share
slots if two variables are live at different points.

Combined, it means LLVM isn't going to make any guarantees that the
order you write your allocas (or anything else you have access to)
dictates the order they get laid out in memory.

Why do you think the single-allocation approach isn't appropriate?
It's really the only way to guarantee you get a block, whether done
via alloca or via callbacks like ASAN.

Cheers.

Tim.

Oh, I see. Regarding single stack allocation i am not sure how it is
possible.
For example for each local variable, I need to maintain a 4-byte metadata.
for example, if it is a 4 bytes variable (e.i. int), I need to allocate 8,
or if it is a struct, let's say 26 bytes, I need to allocate 30 bytes.
How it is possible using AllocaInst?

Thanks in advance

On Fri, Sep 21, 2018 at 9:36 AM Tim Northover <t.p.northover at gmail.com>
wrote:
> Hi Sam,
>
> On Fri, 21 Sep 2018 at 14:05, sam djafari <sami.djafari at gmail.com>
wrote:
> > Thanks for your reply. However, I have seen that addressSanitizer has
> done this by placing redzones around each local variable.
>
> Maybe conceptually, but as far as I can see from the IR ASAN maintains
> a completely separate stack via calls to runtime support (like
> __asan_stack_malloc).
>
> > By doing so, LLVM would place them in the expected order I guess.
>
> I doubt it. Allocating objects on the stack involves a reasonably
> sophisticated algorithm to try and minimize space consumed. Some of
> that involves reordering variables with different sizes so that
> they're contiguous. Some involves lifetime tracking to try and share
> slots if two variables are live at different points.
>
> Combined, it means LLVM isn't going to make any guarantees that the
> order you write your allocas (or anything else you have access to)
> dictates the order they get laid out in memory.
>
> Why do you think the single-allocation approach isn't appropriate?
> It's really the only way to guarantee you get a block, whether done
> via alloca or via callbacks like ASAN.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180921/32d9c865/attachment.html>