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 64A7C3A46C1D for ; Thu, 22 Apr 2021 17:55:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 64A7C3A46C1D 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-287-kfhnN6ktO3OFtRg5QBp4VA-1; Thu, 22 Apr 2021 13:55:52 -0400 X-MC-Unique: kfhnN6ktO3OFtRg5QBp4VA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3CFFC19251A8; Thu, 22 Apr 2021 17:55:51 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-20.ams2.redhat.com [10.36.113.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C0BF35D9C6; Thu, 22 Apr 2021 17:55:49 +0000 (UTC) From: Florian Weimer To: "H.J. Lu" Cc: Szabolcs Nagy , Pedro Alves , Florian Weimer via Libc-alpha , GDB Subject: Re: [PATCH v3] nptl_db: Support different libpthread/ld.so load orders (bug 27744) References: <87tuo24kxi.fsf@oldenburg.str.redhat.com> <87czunoo5m.fsf@oldenburg.str.redhat.com> <20210422072821.GE9028@arm.com> <87o8e6k9br.fsf@oldenburg.str.redhat.com> <20210422090501.GH9028@arm.com> <20210422094808.GJ9028@arm.com> <87pmymildh.fsf@oldenburg.str.redhat.com> <20210422124455.GK9028@arm.com> <20210422142030.GL9028@arm.com> <87pmymgzuy.fsf@oldenburg.str.redhat.com> <20210422153008.GM9028@arm.com> Date: Thu, 22 Apr 2021 19:56:08 +0200 In-Reply-To: (H. J. Lu's message of "Thu, 22 Apr 2021 10:22:15 -0700") Message-ID: <87bla6cifb.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.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-12.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_STOCKGEN, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable 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: Thu, 22 Apr 2021 17:55:58 -0000 * H. J. Lu: > On Thu, Apr 22, 2021 at 10:16 AM Szabolcs Nagy via Gdb-patches > wrote: >> >> The 04/22/2021 16:25, Florian Weimer wrote: >> > * Szabolcs Nagy: >> > >> > > if i rerun the link command of the test exe but with -no-pie >> > > instead of -pie then the test passes with that binary. >> > > >> > > i suspect gdb places the breakpoint at the wrong place in pie >> > > for some reason. can be ubuntu tooling specific. see the >> > > breakpoint location (the exe base offset is missing): >> > >> > Thanks for investigating. >> > >> > > +attach 1254516 >> > > [New LWP 1254517] >> > > Trying host libthread_db library: /home/szabolcs/try/build/nptl_db/libthread_db.so.1. >> > > td_ta_new failed: application not linked with libthread >> > > thread_db_load_search returning 0 >> > > Trying host libthread_db library: /home/szabolcs/try/build/nptl_db/libthread_db.so.1. >> > > [Thread debugging using libthread_db enabled] >> > > Using host libthread_db library "/home/szabolcs/try/build/nptl_db/libthread_db.so.1". >> > > thread_db_load_search returning 1 >> > > 0x0000ffff9d3d89c4 in __futex_abstimed_wait_common64 (futex_word=0xffff9d363210, expected=1254517, clockid=, abstime=0x0, private=, cancel=cancel@entry=true) at futex-internal.c:74 >> > > 74 err = INTERNAL_SYSCALL_CANCEL (futex_time64, futex_word, op, expected, >> > > +break debugger_inspection_point >> > > Breakpoint 1 at 0x20c0: file tst-pthread-gdb-attach.c, line 123. >> > > +continue >> > >> > Would you please check if the issue goes away if you replace >> > >> > "add-symbol-file %1$s/nptl/tst-pthread-gdb-attach\n" >> > >> > with >> > "file %1$s/nptl/tst-pthread-gdb-attach\n" >> > >> > ? >> > >> > (I assume this happens without --enable-hardcoded-path-in-tests.) >> >> yes, it seems gdb does not work with >> >> ld.so ./exe >> >> if exe is pie. i could not get it to work wit file either. > > Just pass -no-pie to build exe. Ah right, the penny finally dropped. I've seen this failure before during regular glibc debugging. Fedora apparently has a downstream-only patch. 8-/ This is what I came up with: nptl: Do not build nptl/tst-pthread-gdb-attach as PIE diff --git a/nptl/Makefile b/nptl/Makefile index a3d1ef8d66..294bb2faa4 100644 --- a/nptl/Makefile +++ b/nptl/Makefile @@ -377,6 +377,9 @@ endif CFLAGS-tst-pthread-gdb-attach-static.c := $(CFLAGS-printers-tests) CPPFLAGS-tst-pthread-gdb-attach-static.c := \ $(CFLAGS-printers-tests) -DDO_ADD_SYMBOL_FILE=0 +# As of version 9.2, GDB cannot attach properly to PIE programs that +# were launched with an explicit ld.so invocation. +tst-pthread-gdb-attach-no-pie = yes ifeq ($(build-shared),yes) tests-printers-libs := $(shared-thread-library) It's not needed for the static test even with --enable-static-pie. Thanks, Florian