<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 12 Nov 2019, at 11:16, Liu, Yaxun (Sam) via cfe-dev wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">+ John Matt<br>
<br>
My comments are below.<br>
<br>
Sam<br>
<br>
-----Original Message-----<br>
From: Y Song <ys114321@gmail.com><br>
Sent: Tuesday, November 12, 2019 10:15 AM<br>
To: cfe-dev@lists.llvm.org<br>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>; Alexei Starovoitov <alexei.starovoitov@gmail.com>; richard@metafoo.co.uk; Liu, Yaxun (Sam) <Yaxun.Liu@amd.com><br>
Subject: Re: Two questions about address_space attribute<br>
<br>
[CAUTION: External Email]<br>
<br>
Hi, Richard Smith and Yaxun Liu,<br>
<br>
You probably have expertise on the two questions below related to address space. Could you comment on my questions below?<br>
<br>
Thanks!<br>
<br>
Yonghong<br>
<br>
On Thu, Nov 7, 2019 at 10:29 AM Y Song <ys114321@gmail.com> wrote:</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">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" style="color:#999">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<br>
not be // 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; typedef __restorefn_t<br>
__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 merely points to<br>
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/...?</p>
</blockquote></blockquote></div>
<div style="white-space:normal">
<p dir="auto">I can’t actually speak for the C committee, but I’ll try to answer anyway. As I understand it, there’s two main things.</p>
<p dir="auto">The first is that data pointers may already be in a different address space from function pointers. Standard C does not actually allow function pointers to be converted to data pointers and vice-versa; that’s an extension, albeit a basically universal one and indeed one mandated by POSIX because of <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">dlsym</code>. Harvard architectures put code in a separate address space, which is often significantly larger than the address space for data, and C supports that. So while it’s not abstractly illogical for the code space to be split into address spaces, the idea of applying the <em>same</em> address spaces to both data and function pointers isn’t totally aligned with C.</p>
<p dir="auto">The second is just that the traditional hardware-supported uses of address spaces are centered around data, not code. A processor might have different instructions to load/store from different address spaces, and handling those different address spaces correctly and efficiently is important to expose in a systems programming language. While processors often also have different instructions for e.g. near/far calls, this is rarely useful to expose in the programming language, since it usually only comes up in e.g. the userspace/kernelspace boundary, which is so important and fiddly that’s it’s usually written in assembly anyway.</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">I think we may allow function to be in a non-default address space. The issue is that there may be lots of places in clang or llvm assuming function in default address space, which needs to be fixed.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Yes, I think LLVM might currently assume a single address space for all code. I would want to see signs of progress on that front before agreeing to an extension of address spaces to function pointer types.</p>
<p dir="auto">John.</p>
</div>
</div>
</body>
</html>