On Thu, Dec 09, 2021 at 09:42:04AM -0700, Martin Sebor wrote:
> On 12/6/21 12:40 PM, Segher Boessenkool wrote:
> >Named address spaces are completely target-specific.
>
> My understanding of these kernel/user address spaces that David
> is adding for the benefit of the analyzer is that the corresp
On 12/6/21 12:40 PM, Segher Boessenkool wrote:
On Mon, Dec 06, 2021 at 11:12:00AM -0700, Martin Sebor wrote:
On 11/13/21 1:37 PM, David Malcolm via Gcc-patches wrote:
Approach 1: Custom Address Spaces
=
GCC's C frontend supports target-specific address spaces; s
Hi!
On Wed, Dec 08, 2021 at 07:06:30PM -0500, David Malcolm wrote:
> On Mon, 2021-12-06 at 13:40 -0600, Segher Boessenkool wrote:
> > Named address spaces are completely target-specific. Defining them
> > with
> > a pragma like this does not allow you to set the pointer mode or
> > anything relat
On Mon, 2021-12-06 at 13:40 -0600, Segher Boessenkool wrote:
> On Mon, Dec 06, 2021 at 11:12:00AM -0700, Martin Sebor wrote:
> > On 11/13/21 1:37 PM, David Malcolm via Gcc-patches wrote:
> > > Approach 1: Custom Address Spaces
> > > =
> > >
> > > GCC's C frontend su
On Mon, 2021-12-06 at 11:12 -0700, Martin Sebor wrote:
> On 11/13/21 1:37 PM, David Malcolm via Gcc-patches wrote:
> > [Crossposting between gcc-patches@gcc.gnu.org and
> > linux-toolcha...@vger.kernel.org; sorry about my lack of kernel
> > knowledge, in case of the following seems bogus]
> >
> >
On Mon, Dec 06, 2021 at 11:12:00AM -0700, Martin Sebor wrote:
> On 11/13/21 1:37 PM, David Malcolm via Gcc-patches wrote:
> >Approach 1: Custom Address Spaces
> >=
> >
> >GCC's C frontend supports target-specific address spaces; see:
> > https://gcc.gnu.org/onlined
On 11/13/21 1:37 PM, David Malcolm via Gcc-patches wrote:
[Crossposting between gcc-patches@gcc.gnu.org and
linux-toolcha...@vger.kernel.org; sorry about my lack of kernel
knowledge, in case of the following seems bogus]
I've been trying to turn my prototype from the LPC2021 session on
"Adding k
On Sat, Nov 13, 2021 at 9:37 PM David Malcolm wrote:
>
> #define __user __attribute__((untrusted))
>
> where my patched GCC treats
> T *
> vs
> T __attribute__((untrusted)) *
> as being different types and thus the C frontend can complain (even without
> -fanalyzer) about e.g.:
This one sou
On Sun, 2021-11-14 at 00:20 +0100, Peter Zijlstra wrote:
> On Sat, Nov 13, 2021 at 03:37:24PM -0500, David Malcolm wrote:
>
> > This approach is much less expressive that the custom addres space
> > approach; it would only cover the trust boundary aspect; it
> > wouldn't
> > cover any differences
On Sat, Nov 13, 2021 at 03:37:24PM -0500, David Malcolm wrote:
> This approach is much less expressive that the custom addres space
> approach; it would only cover the trust boundary aspect; it wouldn't
> cover any differences between generic pointers and __user, vs __iomem,
> __percpu, and __rcu
10 matches
Mail list logo
