<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regarding the Issue 1 - what are you trying to achieve by qualifying function pointers with address spaces? Ideally functions are placed by an implementation.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Cheers,<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Anastasia<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> cfe-dev <cfe-dev-bounces@lists.llvm.org> on behalf of Y Song via cfe-dev <cfe-dev@lists.llvm.org><br>
<b>Sent:</b> 07 November 2019 18:29<br>
<b>To:</b> cfe-dev@lists.llvm.org <cfe-dev@lists.llvm.org><br>
<b>Cc:</b> Andrii Nakryiko <andrii.nakryiko@gmail.com>; Alexei Starovoitov <alexei.starovoitov@gmail.com><br>
<b>Subject:</b> [cfe-dev] Two questions about address_space attribute</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi,<br>
<br>
Currently, I am thinking to add address_space attribute support for<br>
x86_64 and BPF to compile linux kernel. The main goal is to get<br>
address_space information into debug_info and then later to dwarf/BTF.<br>
But address_space enforcement itself can also help with better code<br>
for the kernel.<br>
<br>
The RFC patch is here:<br>
<a href="https://reviews.llvm.org/D69393">https://reviews.llvm.org/D69393</a><br>
<br>
During experiments, we found two issues which I would like to get<br>
expert opinion:<br>
<br>
issue 1: address_space attributes on function pointers<br>
=========================================<br>
<br>
clang does not allow address_space attribute for function pointers,<br>
specifically, in clang/lib/Sema/SemaType.cpp,<br>
<br>
// ISO/IEC TR 18037 S5.3 (amending C99 6.7.3): "A function type shall not be<br>
// qualified by an address-space qualifier."<br>
if (Type->isFunctionType()) {<br>
S.Diag(Attr.getLoc(), diag::err_attribute_address_function_type);<br>
Attr.setInvalid();<br>
return;<br>
}<br>
<br>
But linux kernel tries to annotate signal handling function pointer<br>
with address space to indicate it is accessing user space.<br>
<br>
typedef __signalfn_t __user *__sighandler_t;<br>
typedef __restorefn_t __user *__sigrestore_t;<br>
<br>
Such attribute makes sense for linux since indeed the signal handler<br>
code resides in user space and the kernel pointer<br>
merely points to user memory here.<br>
<br>
What is the rationale for this restriction in standard? How we could<br>
make clang tolerate such restrictions for X86/BPF/...?<br>
<br>
issue 2: typeof(*ptr) where ptr has address_space attribute.<br>
<br>
-bash-4.4$ cat t2.c<br>
int test(int __attribute__((address_space(1))) *p) {<br>
#ifdef NO_TYPEOF<br>
int t = *p;<br>
#else<br>
typeof(*p) t = *p;<br>
#endif<br>
return t;<br>
}<br>
-bash-4.4$ clang -c t2.c<br>
t2.c:5:14: error: automatic variable qualified with an address space<br>
typeof(*p) t = *p;<br>
^<br>
1 error generated.<br>
-bash-4.4$ clang -DNO_TYPEOF -c t2.c<br>
-bash-4.4$<br>
<br>
The IR generated without NO_TYPEOF macro:<br>
%p.addr = alloca i32 addrspace(1)*, align 8<br>
%t = alloca i32, align 4<br>
store i32 addrspace(1)* %p, i32 addrspace(1)** %p.addr, align 8<br>
%0 = load i32 addrspace(1)*, i32 addrspace(1)** %p.addr, align 8<br>
%1 = load i32, i32 addrspace(1)* %0, align 4<br>
store i32 %1, i32* %t, align 4<br>
%2 = load i32, i32* %t, align 4<br>
ret i32 %2<br>
<br>
So we can directly load a i32 addrspacee(1)* to an i32. Maybe<br>
typeof(*p) should just i32 and we should not emit the error at all?<br>
<br>
Thanks,<br>
<br>
Yonghong<br>
_______________________________________________<br>
cfe-dev mailing list<br>
cfe-dev@lists.llvm.org<br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div>
</span></font></div>
</body>
</html>