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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 7AEDD395542A for ; Tue, 29 Jun 2021 09:09:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7AEDD395542A Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-345-x5qD4v0sPMORmCpNO7sM6g-1; Tue, 29 Jun 2021 05:09:29 -0400 X-MC-Unique: x5qD4v0sPMORmCpNO7sM6g-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AC449802C99; Tue, 29 Jun 2021 09:09:28 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-228.ams2.redhat.com [10.36.112.228]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D4D2A369A; Tue, 29 Jun 2021 09:09:23 +0000 (UTC) From: Florian Weimer To: Szabolcs Nagy Cc: Carlos O'Donell , libc-alpha@sourceware.org Subject: Re: [PATCH v3] nptl: Export libthread_db-used symbols under GLIBC_PRIVATE References: <87zgvarwj8.fsf@oldenburg.str.redhat.com> <3974f7a0-2c4a-0654-65cc-84fe6bd80b09@redhat.com> <20210629082135.GO13058@arm.com> Date: Tue, 29 Jun 2021 11:09:21 +0200 In-Reply-To: <20210629082135.GO13058@arm.com> (Szabolcs Nagy's message of "Tue, 29 Jun 2021 09:21:36 +0100") Message-ID: <87o8bpox4u.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, 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 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: Tue, 29 Jun 2021 09:09:37 -0000 * Szabolcs Nagy: > The 06/28/2021 08:59, Carlos O'Donell via Libc-alpha wrote: >> On 6/28/21 8:41 AM, Florian Weimer wrote: >> > This allows distributions to strip debugging information from >> > libc.so.6 without impacting the debugging experience. >> >> This looks good, no redundant checks. The only *MAIN* symbol >> left in structs.def is from ld.so and we skip checking it >> (because the test framework only processes libc.so's symbols). >> >> Reviewed-by: Carlos O'Donell > > after the previous two nptl_db commits i see > > FAIL: nptl_db/db-symbols > > i thought this third patch would fix it, but it didn't: > > $ head nptl_db/db-symbols.out > _thread_db_pthread_eventbuf_eventmask_event_bits@@GLIBC_PRIVATE ***MISSING*** > _thread_db_pthread_start_routine@@GLIBC_PRIVATE ***MISSING*** > _thread_db_sizeof_list_t@@GLIBC_PRIVATE ***MISSING*** > _thread_db_pthread_schedparam_sched_priority@@GLIBC_PRIVATE ***MISSING*** > _thread_db_td_eventbuf_t_eventdata@@GLIBC_PRIVATE ***MISSING*** > _thread_db_list_t_prev@@GLIBC_PRIVATE ***MISSING*** > _thread_db_sizeof_dtv_slotinfo@@GLIBC_PRIVATE ***MISSING*** > _thread_db_pthread_cancelhandling@@GLIBC_PRIVATE ***MISSING*** > _thread_db___pthread_keys@@GLIBC_PRIVATE ***MISSING*** > _thread_db_rtld_global__dl_tls_dtv_slotinfo_list@@GLIBC_PRIVATE ***MISSING*** > > is this expected? It is not expected. The test runs even when cross-compiling, and I don't see this failure in a default build-many-glibcs.py run. Are these symbols present as dynamic symbols in your build of libc.so.6? I suspect your readelf has different output not expected by the script. Apparently older versions do not print symbol versioning information with -D -s. 8-( I guess we should parse ELF directly, rather than readelf output, because it is easier to maintain. As a stop-gap measure, we should probably switch to objdump -T. Thanks, Florian