Hello,
> This can be done with the existing section markings for globals;
> address spaces are intended for situations where the spaces actually
> have distinct properties.
I understand that the spaces hold information with distinct properties. For
this reason, I want to include an extra property (like a security tag). By
profiling, I know which variables hold secure information and which not.
Then, I want to aggregate variables depending on the new property. The idea
is allocate them (secure - unsecure) in different pages (I can afford
wasting memory between segments).
The idea is to apply the same concept to all the segments (text, data, heap,
and stack). At the end, I will have several address spaces (in an ARM
processor), so the only that I will need to do is assign the correct (or
desired) number to each variable.
In other words, I just need to re-order the variables and re-calculate they
offset. Any idea?
Thanks,
Juan Carlos
On Mon, Jul 6, 2009 at 4:11 PM, Eli Friedman <eli.friedman at gmail.com>
wrote:
> On Mon, Jul 6, 2009 at 11:43 AM, Juan Carlos Martinez
> Santos<juanc.martinez.santos at gmail.com> wrote:
> > Looking the Language Reference, there is something called
"addrspace". It
> > can be used to allocate a global variable into a specific area (always
> that
> > the target supports it). How I can modify the ARM back-end in order to
> > support at least two memory sections for Global Variables in the BSS
> > section. My idea is to split the uninitialized global variables in two
> > sections and to aggregate them depends on the uses of each variable at
> > execution time (by profiling I will know what variable will be in each
> > section).
>
> This can be done with the existing section markings for globals;
> address spaces are intended for situations where the spaces actually
> have distinct properties.
>
> > In addition, can I add more address spaces for heap and stack also?
For
> > exampe, can I split my stack in two segments, one to hold critical
info
> like
> > return address and frame pointer, and another to hold function
arguments?
> > How I can do it?
>
> You don't need address spaces for that; it's just a matter of using
> different heap allocation functions and a custom calling convention.
>
> -Eli
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
--
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090706/040bc1aa/attachment.html>