From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id EAFE73861830 for ; Wed, 23 Sep 2020 18:12:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EAFE73861830 Received: from mail-oo1-f72.google.com (mail-oo1-f72.google.com [209.85.161.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-464-eFNYf5pVMkiKy_P1WFh5Og-1; Wed, 23 Sep 2020 14:12:29 -0400 X-MC-Unique: eFNYf5pVMkiKy_P1WFh5Og-1 Received: by mail-oo1-f72.google.com with SMTP id n19so204955oof.4 for ; Wed, 23 Sep 2020 11:12:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:message-id:in-reply-to :references:mime-version; bh=iZrPMcNfiRxBjZ5mJvSFoue6T/kqt4kto5ZOAtCY6EE=; b=DtgwOt0wF0ReKCPv38qM4W5u1alaNgaH1OBEZ6QldYd0YN6cJSKkMiYY2NVFhb+OQ5 0kYKGf1fwQUy50Q9L5e5uW/D7cv9gqUIr6YJ4mC4HjNFOy+XrqCI+KlCETAbpvnsHA09 x/QONdHeqE12vMZAemjQunnlRCGglppio+jzzdJzfIPVDYo3QXYQG+hyTBFslE0IfWYp ofE0UJDFVluDXj2BJ7gMqR8HCRt1TPN5SMH/q/nP0WQ1SYccfa/qlO6wXEwxcEJGisDA abaWACrdbZa51ziAyRVaKwbz+G5Z3W4FJAZDZjn0bKHcxmV4QBOxJy2sYnNIUSVtTdsp ahcA== X-Gm-Message-State: AOAM532RRjUQmPDn0ZB/ZWduE1mG6E39NgE8Mfyo44jOPTckkHb9MjHp oVNM8fRbUPQ2HZS9HHJQ6fFY2L3oF9rw7Sy9mHcUh08F0IzanfNA610s1ApVSwrr38bg8siYHNm rt9ys4j1RKs3sncm1SIs1 X-Received: by 2002:aca:f1d7:: with SMTP id p206mr427741oih.45.1600884748245; Wed, 23 Sep 2020 11:12:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzS2Dy2TRHlB3lsz0Wjj76EW6MJahPmgDQEpY/mehyF15K6RevDRivFKj9/FftFyKcChtg3uQ== X-Received: by 2002:aca:f1d7:: with SMTP id p206mr427725oih.45.1600884747865; Wed, 23 Sep 2020 11:12:27 -0700 (PDT) Received: from [192.168.1.234] (47-208-193-143.trckcmtc01.res.dyn.suddenlink.net. [47.208.193.143]) by smtp.gmail.com with ESMTPSA id k135sm101010oih.16.2020.09.23.11.12.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2020 11:12:26 -0700 (PDT) Date: Wed, 23 Sep 2020 11:12:18 -0700 From: Ben Coyote Woodard Subject: Re: [PATCH] Fix runtime linker auditing on aarch64 To: Szabolcs Nagy Cc: libc-alpha@sourceware.org Message-Id: In-Reply-To: <20200923161927.GH16385@arm.com> References: <20200923011613.2243151-1-woodard@redhat.com> <20200923123426.GD16385@arm.com> <20200923161927.GH16385@arm.com> X-Mailer: geary/3.36.3.1 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, 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 Content-Type: text/plain; charset=us-ascii; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 18:12:34 -0000 On Wed, Sep 23, 2020 at 17:19, Szabolcs Nagy wrote: > The 09/23/2020 08:10, Ben Coyote Woodard wrote: >> On Wed, Sep 23, 2020 at 13:34, Szabolcs Nagy > > wrote: >> > The 09/22/2020 18:16, Ben Woodard via Libc-alpha wrote: >> > > /* Return values for calls from PLT on AArch64. */ >> > > typedef struct La_aarch64_retval >> > > { >> > > - /* Up to two integer registers can be used for a return >> value. >> > > */ >> > > - uint64_t lrv_xreg[2]; >> > > - /* Up to four D registers can be used for a return value. >> */ >> > > - uint64_t lrv_dreg[4]; >> > > + /* Up to eight integer registers and the indirect result >> > > location register >> > > + can be used for a return value. */ >> > > + uint64_t lrv_xreg[9]; >> > >> > x8 is not preserved so recording it at function exit >> > is not useful. (on entry it points to where results >> > are stored but on exit it can be clobbered) >> >> OK that was not clear to me reading the AAPCS. Do you want to ping >> you're >> colleagues the tech writers over at arm and see if they can tighten >> up the >> language a bit. > > aapcs is now openly developed (on github) > so you can submit bug reports easily ;) > > in this case section 6.1.1 does not say > if x8 is preserved or not, but 6.5 is quite > explicit i think: > > > Good enough for me. I either didn't read that section or that last line was not in the earlier version that I read. >> > > + /* Up to eight V registers can be used for a return value. >> */ >> > > + __uint128_t lrv_vreg[8]; >> > > >> > > } La_aarch64_retval; >> > > __BEGIN_DECLS >> > >> > note: i don't like to use non-standard types in >> > public apis (like __uint128_t), but we already >> > made this mistake in the linux sigcontext, so this >> > is probably ok. >> > >> > (my preference normally is to use a standard type >> > e.g. long double or char[] with alignment attr, >> > but in practice __uint128_t is probably easier to >> > deal with) >> > >> >> I kind of prefer "long double" here as well. It is after all what >> it likely >> is. I'm not really attached to __uint128_t; the previous version of >> the >> interface had uint64_t and so when making the registers the correct >> size I >> changed it to uint128_t but that didn't compile and then when I >> grepped the >> source I found __uint128_t. It wasn't like I put a lot of thought >> into that >> decision. > > hm, i think the common case is to inspect float > or double arguments in the v regs, so the > __uint128_t is probably easier for the user > to deal with. (and sigcontext etc already > uses that for save/restore of the registers > so it is better for interop and least surprise) > > it's unfortunate that there is no standard > uint128_t type. (i think the arm way would > be to use "uint8x16_t" or similar type from > arm_neon.h but in practice that's harder > to use) > > so keep this as is. > OK I'll change it back in a V3 version of my patch. Since it is a trivial change, I will wait a bit and see if anyone else has any feedback before I send it. > (but this reminds me that the current hooks > are broken for long double functions, not > just for functions taking neon vector args) Yep and the one that triggered me looking into this code was a function that used x8 to pass a parameter indirectly. The rest of the problems I found by inspection. -ben >