From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id RiZkII/fQmppTR4AWB0awg (envelope-from ) for ; Mon, 29 Jun 2026 17:11:43 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=TMajPEZT; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 741711E098; Mon, 29 Jun 2026 17:11:43 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id EA8041E024 for ; Mon, 29 Jun 2026 17:11:42 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AD0434BA2E12 for ; Mon, 29 Jun 2026 21:11:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AD0434BA2E12 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=TMajPEZT Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id E77E74BA23D6 for ; Mon, 29 Jun 2026 21:11:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E77E74BA23D6 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E77E74BA23D6 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782767478; cv=none; b=t5dAsv+XX2KGP5BVELjkubyfZF4HHGOgaAS6YHhGHmlR1T/MI0yg+OfaHKkIXxYH2ga3EOwEBc8tLN3prp0yXCt/rzmBeACXzsp1bDVJMjQEBM4WjNMWlP2rrnKUfXuO9iXti85zxteHIJ9a/kNbsw4031OkIs/BqdTAzuH2ouw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782767478; c=relaxed/simple; bh=pzYD7jcznFKdOfsXEchq+WzqfHIzkDMuteQpu0uc+1M=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=ZAh/1rltPs0JTLLLWHmbDv6G6bfGZcNYJEe0eW4cjwJMk7zLhqB0MtysticBABzhmEOoUXoqGc06K71MHQMS/VuX8hgI/q0+A4ACYQPyQtq44JQII9xt4iXkbWgcuk4lsqDN6WwuzK4VmLmH43msag5GN5qhiVttRjZN1RqPKNk= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=TMajPEZT DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E77E74BA23D6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782767477; h=from:from: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=4X3NLAeblkiY45G0AAYwZM7+epVwfgqqBdwWHI20OlA=; b=TMajPEZTO6dkfABwtq4SeGMGqJBey4eA3/8cyhCbQi7Kb2ruZkuB690mR9nJUdtmj6M2DO YaYpOu+IsDzjSJqvYxlMbFDpxeLTmfAeSoweWOi6sFxPHU9HSlcdUOOVL2shcxrH+hRZSQ OZzLgoHKGdvtl4wK4B9UUUGXLmKV30k= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-80-tlWmX4y1Pde2eKHYYqMakw-1; Mon, 29 Jun 2026 17:11:14 -0400 X-MC-Unique: tlWmX4y1Pde2eKHYYqMakw-1 X-Mimecast-MFC-AGG-ID: tlWmX4y1Pde2eKHYYqMakw_1782767473 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2F5EB18C0FC1; Mon, 29 Jun 2026 21:11:13 +0000 (UTC) Received: from fweimer-oldenburg.csb.redhat.com (unknown [10.44.48.121]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 54BB119560AD; Mon, 29 Jun 2026 21:11:09 +0000 (UTC) From: Florian Weimer To: Muhammad Kamran Cc: , Andrew Burgess , Wilco Dijkstra , Yury Khrustalev , "Thiago Jung Bauermann" , Adhemerval Zanella Netto , Carlos O'Donell Subject: Re: [PATCH v2 1/1] gdb: Preserve IFUNC marker when finding inferior functions In-Reply-To: <20260625152036.6149-2-muhammad.kamran@arm.com> (Muhammad Kamran's message of "Thu, 25 Jun 2026 15:20:36 +0000") References: <20260625152036.6149-1-muhammad.kamran@arm.com> <20260625152036.6149-2-muhammad.kamran@arm.com> Date: Mon, 29 Jun 2026 23:11:07 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: STF-KX6jEOOCeEuapCmg9F_I0AY2JhMiEctdLqsjDgI_1782767473 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org * Muhammad Kamran: > GDB calls find_function_in_inferior ("malloc") when expression > evaluation needs to allocate memory in the inferior, e.g. for string > literal arguments. So this looks fairly nasty. This looks fairly harmless as far as GDB expressions go: > + gdb_test "print (get_string (\"hello-ifunc\"), str_in_arena ())" \ We can actually detect the GDB call and glibc and do the right thing: [PATCH 0/2] Work around GDB bug overwriting __libc_malloc Of course the GDB bug still needs fixing. By the way, I don't think there is a safe way for GDB to call IFUNC resolvers. IFUNC resolvers in glibc may assume the presence of extra data that was not there in the initial definition of the interface. This shouldn't matter for malloc: elf_gnu_ifunc_resolve_by_got should always be able obtain the pre-relocated address (except before relocation has happened). Does your patch change the behavior and output of this? (gdb) print strcpy $1 = {} 0x7ffff7e0b8f0 Currently, the workaround looks like this: (gdb) print dlsym(0, "strcpy") $2 = (void *) 0x7ffff7ecb970 <__strcpy_avx2> Maybe going through dlsym would also be the right way to do the inferior calls involving IFUNC resolvers. We can also provide a symbol that GDB can call to make the IFUNC resolver call, given its handler address. Thanks, Florian