Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane

From: Philip Reames <listmail <at> philipreames.com>
Subject: Re: Is address space 1 reserved?
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Wednesday 7th January 2015 20:20:29 UTC (over 3 years ago)
On 01/07/2015 11:57 AM, Nick Lewycky wrote:
> On 7 January 2015 at 11:25, Owen Anderson  > wrote:
>
>     I'm not aware of any such restriction, and I know of several LLVM
>     based systems that use address space 1 for something other than that.
>
>
> Oof. It was discussed when the patches to add addrspace were being 
> considered, and this is why we should've written it down.
>
> It would be nice to have an addrspace that does mean "same as 
> addrspace(0) except that null may be dereferenceable", and to attach 
> that to -fno-delete-null-pointer-checks. Any ideas for what that 
> addrspace should be?
 From what I can tell, that flag combines two semantics:
1) An object can live at null, null is dereferencable.
2) Null checks should not be eliminated base on a previous dereference 
of that location.

I suspect most usage is for the second, probably for security mitigation 
in legacy programs.  Using an address space seems like a great solution 
for a use case which actually requires both, but I'd be tempted to try 
something else for security mitigation.  I wonder how far we could get 
performance wise by null checking *every* access and then optimizing 
them away?  This is strictly stronger.

Returning from that tangent, I'm not arguing against the reservation of 
such an address space.  Since we seem to have precedent for larger 
numbers meaning reserved things, why don't we document the following?
0 - current meaning, default
1-127 - reserved for custom extensions, no defined special semantics in 
upstream
128 - like address space zero, but null is dereferenceable
129-255 - reserved for future generic usage
256+ - reserved for generic target specific address spaces

(This is strictly a strawman proposal; I have no attachment to this 
suggestion.)


>
>     -Owen
>
>     On Jan 7, 2015, at 1:18 PM, Philip Reames
>     > wrote:
>
>>     On the review for http://reviews.llvm.org/D6808,
majnemer
>>     <http://reviews.llvm.org/p/majnemer/>
commented that:
>>     "Address space 1 has a special meaning in LLVM, it's identical to
>>     address space 0 except for the fact that "null" may be
>>     dereferenced. You might want to consider a different address space."
>>
>>     This is the first I've heard of this and I can't find any
>>     documentation about it being reserved, either in general, or
>>     specifically for x86.  Can anyone clarify?
>>
>>     The only address spaces with special meanings I know of are:
>>     - 0 (the normal address space, null is not dereferencable)
>>     - 256 - TLS, GS relative addressing
>>     - 257 - FS relative addressing
>>
>>     Philip
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     [email protected] 
>>     http://llvm.cs.uiuc.edu
>>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>     _______________________________________________
>     LLVM Developers mailing list
>     [email protected] 
>     http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
 
CD: 15ms