From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id A80B7385702F for ; Mon, 31 Aug 2020 13:14:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A80B7385702F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=mittosystems.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jozef.l@mittosystems.com Received: by mail-wr1-x42c.google.com with SMTP id m6so3687658wrn.0 for ; Mon, 31 Aug 2020 06:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mittosystems.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=njlnQmtACOtc2b73C1FzUDj7ht0ptMRaP/MXfTdjOGY=; b=Iq2lEq2w70Yq9ifi7AMhl1HWMM6JyHJvtroYs0WHxjJbBvLVVqyaDPzGZJ6LNqmMMB 3yV4qAHhh4gQk/um58Eci7AHlAd/ZgfL7Nelc8etadjsqnZEmFK/B8DwCEBjRI8XVkhT ijl17yGuNL8YCftXFaOBZyYUfh1OICT1GGi9+dHoh82V055oaZjaeFTIM4pC4S00NDFx WvcJu1fyJOPNr53JNFtUJXWHhFocJiz2rEbo9kX0BUAhQAgire7LLQDVt2cryGx7IcfP GvqvL+O6ItFXqQMugc5LC75cJ5BVsd8ZLPU9l7Crjwtzx668mShFdDc61Nc0CMoDCb5R QaCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=njlnQmtACOtc2b73C1FzUDj7ht0ptMRaP/MXfTdjOGY=; b=GtYY+CezDvYTCuNA6lqpcRkdeyPESN+aTUXibVouPXtKilpo3jFHC2mkRuts93KvwC 0L6grtQmoamJeSpi851iLTSiUAMv6XSTHFaabD6341lUU8zk0Eq4PZZGcPmzCDNEgdU1 Hyb2nR4vgT3r1QXCN5/jXtb745qoWKWbIiBwddKfQ/KbKm9XYwbLHZM81kvKSGUjEAE8 3NWQnmqZPZnKG/cPSZI67OWeyjtmrES1yFyO7j01rUIAPKzKJB7qbGPSodfuwfAkH72p I72mmdmo5VrgblaB+zDJQE40sdDU8yyf2uUWT0y7c+NDInlgT7+igydlXiHc99hp26bU WZog== X-Gm-Message-State: AOAM530aBhmwmb7sMvwCs5JiaykrqNbYWZ3XYK3lpIyUxh2I5jnhOgLA sCZhjexXSl3Yaa2s+l6F7DYyTQ== X-Google-Smtp-Source: ABdhPJzX9ix/agvTF8GNXpImxfGDs+UvNsuAc5myNO+4pUh8BvLwe02jvuNxwsNjnn4micZdkmmF+Q== X-Received: by 2002:a05:6000:1c7:: with SMTP id t7mr1234309wrx.95.1598879667596; Mon, 31 Aug 2020 06:14:27 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id m8sm12106861wro.75.2020.08.31.06.14.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Aug 2020 06:14:27 -0700 (PDT) Date: Mon, 31 Aug 2020 14:14:25 +0100 From: Jozef Lawrynowicz To: Florian Weimer Cc: gnu-gabi@sourceware.org Subject: Re: [RFC] Proposal for new ELF extension - "Symbol meta-information" Message-ID: <20200831131425.lqj5rg4i3wh6wvdr@jozef-acer-manjaro> References: <20200831115859.mwcruabbzoj3x4w7@jozef-acer-manjaro> <875z8zj95u.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875z8zj95u.fsf@oldenburg2.str.redhat.com> X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: gnu-gabi@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnu-gabi mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 13:14:32 -0000 On Mon, Aug 31, 2020 at 02:23:57PM +0200, Florian Weimer wrote: > * Jozef Lawrynowicz: > > > I wonder if it is appropriate for inclusion in the GNU gABI or if we > > should just add it to a processor-specific ABI. However, it is being > > used downstream for MSP430 and ARM targets, in GCC and Clang/LLVM > > respectively. So we'd like to have it standardized somewhere generic > > so that different targets and toolchains can align on it. > > Is there an expectation to upstream these changes? In the present state > there does not seem to be need for such coordination. Yes, one way or another I will upstream the functionality to the GNU toolchain, as an MSP430-specific feature if that is what ends up being the only approved route. TI are also looking to upstream their ARM Clang/LLVM implementation. I posted an RFC for an initial version of the functionality to Binutils back in February, but H.J. Lu pointed out that discussions about ELF extensions should be had on the ELF gABI mailing list. https://sourceware.org/pipermail/binutils/2020-February/110236.html So I've been looking for where best to place this functionality before finalizing the spec and implementation. The functionality has been improved and extended since then, I would say the initial version is generally ready for upstreaming after a bit of additional tidying. > > > 3.3.3 SMT_PRINTF_FMT use case > > Can this achieved in C++ with a library-only solution? So that > > printf ("%s", str); > > and > > printf ("%f", num); > > resolve to different printf symbols externally? When code size is a concern, we'd always avoid using C++ for a library. The user would probably rather just manually choose the correct printf function by defining a symbol at link time than take on the C++ burden of having it done automatically. Below I've included some additional clarifications on SMT_PRINTF_FMT that came up from the discussions on the ELF gABI mailing list. Thanks, Jozef > > Thanks, > Florian > --- On Thu, Aug 27, 2020 at 08:43:56PM +0000, Joseph Myers wrote: > I think this is rather under-specified. A format conversion specification > has six parts in ISO C: the initial '%', any flags, any field width, any > precision, any length modifier, the conversion specifier character. > POSIX extends this by allowing the initial '%' to be of the form '%n$' > instead to specify the position of the argument converted, and also allows > '*m$' as a form of width and precision, similarly. > > Do you intend the .strtab_meta entry to contain all those parts of the > conversion specification, or only some of them? The intention would be to omit any digits used by the width and precision specifiers, and the '.' used by the precision specifier, but otherwise store all parts of the format string, de-duplicating parts of it as necessary. The exact behavior of how to encode the format string certainly does need clearer specification. '%' doesn't actually need to be stored in the condensed string, so the behavior should instead be like the below examples: printf ("%-*.*hhd %#hx", ...); yields the following NUL terminated string -*hhd#hx printf ("%+ld % 8.8lld %-6.6lld", ...); yields the following NUL terminated string +ld lld- printf ("%*2$.*3$lld %4$*5$.*6$ld", ...); yields the following NUL terminated string *$lldld It's assumed that the number of the positional argument used with "%n$" or "*m$" isn't important, but the presence of '$' is required as it indicates an additional feature which might need to be supported by printf. There also needs to be a clarification on how to group the parts of the format string when performing the de-duplication. For example, "%ld %lld %lf" should *not* be condensed into "ldllf", as the linker may want to know which length modifier is used by a given conversion format specifier. Instead it should be condensed to "ldlldlf". The length modifier and format specifier are considered an atomic part of the format string for the purposes of de-duplication.