From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by sourceware.org (Postfix) with ESMTPS id 9C9C23851C1A for ; Thu, 5 Nov 2020 12:24:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9C9C23851C1A Received: by mail-ej1-x642.google.com with SMTP id s25so2332309ejy.6 for ; Thu, 05 Nov 2020 04:24:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9am6peUHVo144tBh7bZj2grCvubXI1snoDwTXe+NzLg=; b=rZXiCl8AF8I8OdwC0z5lamJenRzMsQho3fcYYROrmaW7FuadxsQSFLsmQlRARZfnMi KKWLRoALoY2KexqayMIAD6YWwggwv61o1DAKZ0swyrVbLno7P96/2WgWSevcqqo3Q9ux /wIwc0DbDOWp4FjnapkbhjNnLSBqlbOTIkzVKYoyFydR6PIrAuSh4JpT4NQwTciUbWad UifaYGz1PBE4H4KqR4p70Xghrj6zMb0hGQY7R21bM1p7aCwzaH3rbMN4v6cjD4iq+mON xmamG5mOYA56iyEDFH2r0ZeNipHH79mN3jTDqif2RQMPhAfW5Pom1zs85MHaW6rLre44 qt0g== X-Gm-Message-State: AOAM533g8x8jAPeOBLKADFyvqVt60uzknvqk3ExuLf2B5am81MWUKanB KMQ0lnHQTDvKHecERfeazu84jXpgwB0l2rjI/94= X-Google-Smtp-Source: ABdhPJz8M8Dzi+niURkfS37dDo51seCInuk+tpe/LdmDHWaE45CkyB+cA0j2m0mag+OESszosbI2I9eIjJSMzDhIGu0= X-Received: by 2002:a17:906:3acd:: with SMTP id z13mr2108117ejd.118.1604579081415; Thu, 05 Nov 2020 04:24:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 5 Nov 2020 13:24:30 +0100 Message-ID: Subject: Re: typeof and operands in named address spaces To: Alexander Monakov Cc: Uros Bizjak , Jakub Jelinek , GCC Development , X86 ML , Andy Lutomirski Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 12:24:44 -0000 On Thu, Nov 5, 2020 at 1:16 PM Alexander Monakov via Gcc wrote: > > > > On Thu, 5 Nov 2020, Uros Bizjak wrote: > > > On Thu, Nov 5, 2020 at 12:38 PM Alexander Monakov wrote: > > > > > > On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote: > > > > > > > > What is the usecase for stripping the address space for asm operands? > > > > > > > > Please see the end of [2], where the offset to is passed in %rsi > > > > to the call to this_cpu_cmpxchg16b_emu. this_cpu_cmpxchg16b_emu > > > > implements access with PER_CPU_VAR((%rsi)), which expands to > > > > %gs:(%rsi), so it is the same as %gs: in cmpxchg16b alternative. > > > > The offset is loaded by lea , %rsi to %rsi reg. > > > > > > I see, thanks. But then with the typeof-stripping-address-space solution > > > you'd be making a very evil cast (producing address of an object that > > > does not actually exist in the generic address space). I can write such > > > a solution, but it is clearly Undefined Behavior: > > > > > > #define strip_as(mem) (*(__typeof(0?(mem):(mem))*)(intptr_t)&(mem)) > > > > > > void foo(__seg_fs int *x) > > > { > > > asm("# %0" :: "m"(x[1])); > > > asm("# %0" :: "m"(strip_as(x[1]))); > > > } > > > > > > yields > > > > > > foo: > > > # %fs:4(%rdi) > > > # 4(%rdi) > > > ret > > > > > > > > > I think a clean future solution is adding a operand modifier that would > > > print the memory operand without the segment prefix. > > > > I was also thinking of introducing of operand modifier, but Richi > > advises the following: > > > > --cut here-- > > typedef __UINTPTR_TYPE__ uintptr_t; > > > > __seg_fs int x; > > > > uintptr_t test (void) > > { > > uintptr_t *p = (uintptr_t *)(uintptr_t) &x; > > uintptr_t addr; > > > > asm volatile ("lea %1, %0" : "=r"(addr) : "m"(*p)); > > > > return addr; > > } > > This is even worse undefined behavior compared to my solution above: > this code references memory in uintptr_t type, while mine preserves the > original type via __typeof. So this can visibly break with TBAA (though > the kernel uses -fno-strict-aliasing, so this particular concern wouldn't > apply there). > > If you don't care about preserving sizeof and type you can use a cast to char: > > #define strip_as(mem) (*(char *)(intptr_t)&(mem)) But in the end, on x86 the (uintptr_t)&x cast yields you exactly the offset from the segment register, no? The casting back to (uintrptr_t *) and the "dereference" is just because the inline asm is not able to build the lea otherwise? that said, sth like asm volatile ("lea fs:%1, %0" : "=r"(addr) : "r" ((uintptr_t)&x)); with the proper asm template should likely be used. Of course in case the kernel wants transparent handling of non-fs and fs-based cases that will be off. Richard. > > Alexander