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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 3CBA73840127 for ; Tue, 13 Dec 2022 09:59:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3CBA73840127 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670925588; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=ipGP5qosWGrq2RuovZUiyEKJr/vUm0edpJ2H+RcNtJ8=; b=HPZQPG7y/sWPB6wTJ1vI1WuVA/GDfli2P1ha4W9dHcQ1+xMhZH4NbUu93RYV/I5nCE4YWm C+IO/Fe15McbAZ4gCENhAasYeRQJLFLdqBiyosBqCVogyuR9ytsgPQf7wPMP/yfw9jyzRB 4HXLx8coQ759sQFYxc/4u3YQIMYtKdY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-453-_t4vMO5OPX-W-EGLW714WQ-1; Tue, 13 Dec 2022 04:59:45 -0500 X-MC-Unique: _t4vMO5OPX-W-EGLW714WQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7A1C7101A528; Tue, 13 Dec 2022 09:59:45 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.114]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3470853A3; Tue, 13 Dec 2022 09:59:45 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 2BD9xerS1939470 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 13 Dec 2022 10:59:40 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2BD9xdIf1939469; Tue, 13 Dec 2022 10:59:39 +0100 Date: Tue, 13 Dec 2022 10:59:38 +0100 From: Jakub Jelinek To: Jonathan Wakely , Ian Lance Taylor Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: [PATCH] libstdc++: Update backtrace-rename.h Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Dec 13, 2022 at 09:50:23AM +0000, Jonathan Wakely via Gcc-patches wrote: > On Tue, 13 Dec 2022 at 09:44, Jakub Jelinek wrote: > > > > Hi! > > > > When writing the r13-4629 commit log I've realized that libsanitizer > > isn't the only place which nowadays renames libbacktrace symbols, > > libstdc++ does that too. > > > > Ok for trunk if this passes bootstrap/regtest? > > OK, thanks. > > When we move the backtrace symbols from libstdc++_libbacktrace.a into > libstdc++.so we probably want to look into removing the symbols we > don't actually use. Renaming them to our private namespace is good, > but not including them in the library at all would be better. Most of them I assume are actually used, the reason they aren't static is that libbacktrace contains multiple TUs and some APIs are used to interface between the TUs. __attribute__((visibility ("hidden"))) would work for shared libraries and targets where it actually works, but we still have the *.a libraries where such symbols are visible, so I think some renaming is needed. Though, my understanding of backtrace_uncompress_{lzma,zdebug,zstd} is that those are there just as small wrappers for make check purposes only, so I bet those symbols could be easily removed (say by not defining them at all if their names are macros, then we could keep them in backtrace-rename.h as is). > > 2022-12-13 Jakub Jelinek > > > > * src/libbacktrace/backtrace-rename.h (backtrace_uncompress_zstd): > > Define. > > > > --- libstdc++-v3/src/libbacktrace/backtrace-rename.h.jj 2022-09-01 09:37:58.452624676 +0200 > > +++ libstdc++-v3/src/libbacktrace/backtrace-rename.h 2022-12-13 10:41:14.551699599 +0100 > > @@ -16,6 +16,7 @@ > > #define backtrace_syminfo __glibcxx_backtrace_syminfo > > #define backtrace_uncompress_lzma __glibcxx_backtrace_uncompress_lzma > > #define backtrace_uncompress_zdebug __glibcxx_backtrace_uncompress_zdebug > > +#define backtrace_uncompress_zstd __glibcxx_backtrace_uncompress_zstd > > #define backtrace_vector_finish __glibcxx_backtrace_vector_finish > > #define backtrace_vector_grow __glibcxx_backtrace_vector_grow > > #define backtrace_vector_release __glibcxx_backtrace_vector_release Jakub