From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id 397FE386F804 for ; Tue, 1 Sep 2020 12:19:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 397FE386F804 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-x436.google.com with SMTP id x14so1267436wrl.12 for ; Tue, 01 Sep 2020 05:19:25 -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=CIbjiUqbLe331nDLMvaBNNFD00indQg45TVrOZqkG7o=; b=oJt6NuqZh8DIqK4s/PQHi+0ySRSeMnJBB2DJEn+zEeAHopWhQxPO/GW8lNOR4bPllN +q9uA9GcwGBnElgv+wr7W1c6LbhotB3n7dMSgjlla+b3LhcRruxc3OsI8QPALD0uwOrl GX2STPYUB8LgbZ/3HWfCwO8dJC0Ya58uA755oAI5oW+abJR23k9JB/1T5Cxle5wOII2l r+GUTQ970/M+W2aRW6NwpDVSj1yPpoQFEygWPZQ8Ha+iwICb+73OCb/afbWlPuhTqHMs SfYzkEVcT8YwcpBRGWYDLV5snrLq4AJ/CfdyqXuwjK/JLCirl0trYq/0UNIkIyibarKr 43ug== 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=CIbjiUqbLe331nDLMvaBNNFD00indQg45TVrOZqkG7o=; b=gS8xRXpWfw3dzTUEhmgGChtO6qXQaesJ4jH2LEaba+W8vEf9tBmqaVsAMhiXAIKdJD 7y1EmtdVRHkLHOnxdzoEVwg6/tSbj4JviwDxK5qNsT+VYFw5owdDyZx+9/gEkSicn/RI 6stHWCdFp5vzkCNOMFIAd5UxibD5MGvFEk5AMJ9Htov7vTJqg96HIisODLjrrs6Bgflu iTOqUDGbckspMx0tXkUz+Bn/Vm5KzqXDz8VK2RdGPR7IYCAp09M8+bKGbKU0W3AezVdI Dji2YYHbHt99kksh+rS7NxB3tkZ3YbgKr8K1SjiW0ZMT/pqT0N1bKUNl0gjXsEpZTifn dxRA== X-Gm-Message-State: AOAM531vZG5zZDbiw7IU9pZIqEwG5ZSKGet2iEkh5+6YkBGcpm1mBDeZ VIGIb2G9meiGFDszjw4CKAP1TA== X-Google-Smtp-Source: ABdhPJy39DawXtoD54jZcTq0zFSNWmetZKwlzDtX9StF4ykp6sAHCOo3aAP7kyGRv+Nb8/PJFMBfZw== X-Received: by 2002:adf:e7c3:: with SMTP id e3mr1642517wrn.356.1598962764173; Tue, 01 Sep 2020 05:19:24 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id 21sm2245774wrc.55.2020.09.01.05.19.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Sep 2020 05:19:23 -0700 (PDT) Date: Tue, 1 Sep 2020 13:19:22 +0100 From: Jozef Lawrynowicz To: Florian Weimer Cc: James Y Knight via Gnu-gabi Subject: Re: [RFC] Proposal for new ELF extension - "Symbol meta-information" Message-ID: <20200901121922.srcmdfc4o4rd62go@jozef-acer-manjaro> References: <20200831115859.mwcruabbzoj3x4w7@jozef-acer-manjaro> <875z8zj95u.fsf@oldenburg2.str.redhat.com> <87sgc1u4jz.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sgc1u4jz.fsf@oldenburg2.str.redhat.com> X-Spam-Status: No, score=-5.4 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: Tue, 01 Sep 2020 12:19:26 -0000 On Tue, Sep 01, 2020 at 01:20:16PM +0200, Florian Weimer via Gnu-gabi wrote: > * James Y. Knight via Gnu-gabi: > > > On Mon, Aug 31, 2020 at 8:24 AM Florian Weimer via Gnu-gabi < > > gnu-gabi@sourceware.org> wrote: > > > >> > 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? > >> > > > > The LLVM backend optimizer already does this automatically for XCore, TCE, > > and Emscripten targets, without interrogating the format string, or adding > > anything to the object format. > > > > On all three: if there are no floating-point arguments to the call, it will > > translate {s,f,}printf -> i{s,f,}printf. Otherwise, on emscripten only, if > > there are no 128-bit float arguments, it will translate {s,f,}printf -> > > small_{s,f,}printf > > It's not what I had in mind with my C++ comment (I thought about using a > constexpr construct to parse the format strings), but it's simpler to > just look at the types. > > I think we could guide this by some attribute machinery for C, > especially if it is completely type-dependent. If the symbol choice is > determined by that, it is not necessary to maintain the symbol selection > in very different places (the library implementation *and* the linker). > This is main thing I do not like about SMT_PRINTF_FMT: it needs very > library-specific code in the link editor. I am not against removing SMT_PRINTF_FMT as a generic metainfo type, since it is not necessarily the most straightforward way to achieve the desired behavior. TI are using it in conjunction with another vendor-specific metainfo type which tries to work out the format-specifiers used by a printf() call which has a non-constant string used for the format argument. So perhaps SMT_PRINTF_FMT is only really required when used with that other type which requires visibility of the full program, not individual compilation units. I can imagine how the behavior could be implemented without any special handling from the linker, if the compiler instead maps the printf calls to the minimum required printf implementation, and the library has something like this: printf_double (const char *fmt, ...) { return printf_generic (...); } printf_generic (const char *fmt, ...) { if (printf_double != 0) /* Check for compiler emitted symbol. */ return printf_double_1 (...) /* Call real worker function. */ else if (printf_float != 0) return printf_float_1 (...) else if (printf_int != 0) return printf_int_1 (...) .... } Do you have any opinions on the inclusion of the symbol meta-information mechanism itself within the GNU gABI? Thanks, Jozef > > Thanks, > Florian >