* [PATCH] libstdc++: Update backtrace-rename.h
@ 2022-12-13 9:44 Jakub Jelinek
2022-12-13 9:50 ` Jonathan Wakely
0 siblings, 1 reply; 3+ messages in thread
From: Jakub Jelinek @ 2022-12-13 9:44 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: gcc-patches, libstdc++
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?
2022-12-13 Jakub Jelinek <jakub@redhat.com>
* 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] libstdc++: Update backtrace-rename.h
2022-12-13 9:44 [PATCH] libstdc++: Update backtrace-rename.h Jakub Jelinek
@ 2022-12-13 9:50 ` Jonathan Wakely
2022-12-13 9:59 ` Jakub Jelinek
0 siblings, 1 reply; 3+ messages in thread
From: Jonathan Wakely @ 2022-12-13 9:50 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches, libstdc++
On Tue, 13 Dec 2022 at 09:44, Jakub Jelinek <jakub@redhat.com> 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.
> 2022-12-13 Jakub Jelinek <jakub@redhat.com>
>
> * 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
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] libstdc++: Update backtrace-rename.h
2022-12-13 9:50 ` Jonathan Wakely
@ 2022-12-13 9:59 ` Jakub Jelinek
0 siblings, 0 replies; 3+ messages in thread
From: Jakub Jelinek @ 2022-12-13 9:59 UTC (permalink / raw)
To: Jonathan Wakely, Ian Lance Taylor; +Cc: gcc-patches, libstdc++
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 <jakub@redhat.com> 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 <jakub@redhat.com>
> >
> > * 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-12-13 9:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-13 9:44 [PATCH] libstdc++: Update backtrace-rename.h Jakub Jelinek
2022-12-13 9:50 ` Jonathan Wakely
2022-12-13 9:59 ` Jakub Jelinek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).