From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id pD5CF2Wo3GiEohoAWB0awg (envelope-from ) for ; Wed, 01 Oct 2025 00:04:53 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=xzEkPyvk; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4E51F1E04C; Wed, 01 Oct 2025 00:04:53 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 9A19C1E04C for ; Wed, 01 Oct 2025 00:04:51 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B81A43858D1E for ; Wed, 1 Oct 2025 04:04:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B81A43858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1759291490; bh=/JWfUMxPWayJXgBdWLQbGI7+k4bMIi9WoXw2cjhng/E=; h=Date:Subject:To:References:Cc:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=xzEkPyvkAvdG0X2NXxohMJqBUqz5mxTVzDh6e0IkEXj+ZYQ5VEJae/9lboGFTGdm6 auGYS3usjUxlahw37joMpD6/12oyb05f7iMOLMvp4qsnGkv4KsOAXtJpkhYA8v7ebo ZjhlZ9OaP28KVBNFiuyFeWXYNQUwTjFkyzVYbH+g= Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) by sourceware.org (Postfix) with ESMTPS id 1B9623858D20 for ; Wed, 1 Oct 2025 04:03:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1B9623858D20 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1B9623858D20 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1759291439; cv=none; b=BmupY/E+1zIx9OBRDG1qcfgqlwrR2bl5JJ0/nR5NyGGZf3eVs6osusa1QAbp6ikJqucp7iPhNWunD8Pn6RlQl5/L4yuiDD1VTqdPDU8Z3QRc1Jp+Kr1NK2sLRReSAfoa6WCCrwpFjfvsNOO64tcvmPXmJ1BfjY+1voCnIuM5UNs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1759291439; c=relaxed/simple; bh=RapiE6080ZATbrf3mlBPtFbQphZzltHIajDuj3CQMAA=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=QDf/zSoYhNdtCpYwWHXSQTfeglNTp5BdSZhrSgw6c+3ebaKRIvBzIZ0pi/FAjhLrWtysG0M0gPFs72kE3OuY8u6VR4iK2FMTeJQ787ssPuG6jDp76TBwscJccNuwi9jy58BHbYbdKByAujVFmbYpsygMTJhsZn3gCo6/iI4+Xko= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1B9623858D20 Received: by mail-il1-x144.google.com with SMTP id e9e14a558f8ab-426f9f275b2so24210455ab.3 for ; Tue, 30 Sep 2025 21:03:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759291433; x=1759896233; h=content-transfer-encoding:in-reply-to:cc:content-language:from :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/JWfUMxPWayJXgBdWLQbGI7+k4bMIi9WoXw2cjhng/E=; b=A0FVSfNRBJlKHuk9Nwv4E0I82oDEevOHuJkNQnjZMhy8bylXkhghcc/bbkG4vVEYjA ESok3qt2NdC50sePD/lYyAAPAHUNHeps5V9ADaJkPrHoF/OgfpE5N18y7UVJl4ECOU3n NU1hmHsA4a0Ag8lf9FUefRX8U6jBjpCNR996I0+Do280GwDee+B8IOmhcMuy4lvlsArF wcss9yUalfXuPm2Y5AmmCXszL+ZPBsz2pficCHk26rN43Y9aJaIB9Txk/KCJqVm2Dopd Me0+iQkQWOKaiU0xcfEi4AzFf31C3O45IH++Uidt4IywqkAUuQKYPANIx8BvoOQYxhNk BJ5g== X-Forwarded-Encrypted: i=1; AJvYcCV7j9OP9tTrRNOLlTRyXw8QY/LKgk1V4cSNbOs/l+wyRYg0lEzmqJqGSjXcYxRRzSzotCU=@sourceware.org X-Gm-Message-State: AOJu0YzVeR8RZSdV+ZNlMHiapUJdlFDJje0d+pjyt551K0qRtOUbaqoS Fw9x88j70FMDvp75mutkvZXeOb20v7+CEZVYBo/aWGqtnrzBjX/wW9qnH1YY6rcP0uo= X-Gm-Gg: ASbGncsbMqzx7aLOXyjpIjhUx8nG8ZbyltFpiLzXtdSRtNohKuAZdMnD/mAZns6hbLw 1gLXjc0/J3snflJAFjd6Dhmmwpso2Dhu6S6t+yzXc9D4eU5/YOK94N3mrrhWBsK1nM37Y84Z7UL WydOkHifaCmXDuzayC42rChXijphtJ4yNCpeVS9aMHnqM7kktU2aS70xJjsEMLcavuJV4wN18S+ zBkDcBDni3Ci8eqvXS+E5cErotrq2gvpMU7IELCKCYxmOd/Kw9woMFxZMPa3w4z6r7ZIdvT47Jg B5kJnwS45ZN6+pQmwZ6iPOoqDP3+hkw9jIuMdgfAg0c1Mz5g7OKODWaCDCwx8w4A+gZ6HqdjBUX WTxcZx5uqWgmWnX0O0l72FaavdYA4vdblxR9eYwNOJHs0We5EqsPLU+uE6uG9B89nqIrohXEqLo JhaupE8cdmSxzvkuV8kSvgB6AmBfdzNg== X-Google-Smtp-Source: AGHT+IFQkz7QF6Rmg3p9pnMKEVSZ2OY7Zg81mh39qg2sy4psvm7BEUU2f1IgKSrxaw8HyrDJ3RrP+g== X-Received: by 2002:a05:6e02:1aaf:b0:424:1774:6915 with SMTP id e9e14a558f8ab-42d816124c9mr34227865ab.8.1759291433018; Tue, 30 Sep 2025 21:03:53 -0700 (PDT) Received: from [192.168.86.35] (syn-174-082-221-071.res.spectrum.com. [174.82.221.71]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-5753c50a188sm2213044173.31.2025.09.30.21.03.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Sep 2025 21:03:52 -0700 (PDT) Message-ID: Date: Tue, 30 Sep 2025 23:03:51 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: gdb does not stop at printf for ppc To: Sachin Monga , libc-help@sourceware.org, "libc-alpha@sourceware.org" , gdb@sourceware.org References: Content-Language: en-US Cc: Segher Boessenkool , Michael Meissner , Surya Kumari Jangala , Carl Love In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Peter Bergner via Gdb Reply-To: Peter Bergner Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Adding Carl, Mike, Segher and Surya to the CC for their input, so I'm leaving Sachin's entire question for them to see. I'm also CCing the libc-alpha and GDB lists for wider exposure, since this is an actual BUG. My reply is at the end of Sachin's questions. On 9/25/25 2:47 AM, Sachin Monga wrote: > Hi Stewards > > > Summary: > > There is a test case in GDB where printf is getting converted into > __printfieee128 when program is compiled with "--no-builtin" flag. > The program is working fine on a machine with glibc 2.34, but not on > another machine where glibc 2.40 is installed. > > > Test program: > $ cat test.c > #include > > int > main () > { > printf ("Hello World!\n"); > return 0; > } > > GDB operation: > 1. Load the binary > 2. Break main > 3. Run > 4. Once program stops at main, then Break printf > 5. Continue > > Expected ouput: GDB should stop at printf function > > Actual Output on Machine1(with glibc 2.34) : GDB stop at printf symbol > > Actual Output on Machine2(with glibc 2.40) : GDB does NOT stop at printf > symbol > > > Analysis: > Glibc debug package with source is required. Once it is installed. > Then program is working fine with glibc 2.34, but not where glibc 2.40 > is installed. > > > 1. Install debug info package for glibc > sudo dnf debuginfo-install glibc > > Machine1: glibc packages > $ rpm -q glibc glibc-debuginfo glibc-debugsource > glibc-2.34-168.el9_6.23.ppc64le > glibc-debuginfo-2.34-168.el9_6.23.ppc64le > glibc-debugsource-2.34-168.el9_6.23.ppc64le > > > > Machine2: glibc 2.40 packages > $ rpm -q glibc glibc-debuginfo glibc-debugsource > glibc-2.40-28.fc41.ppc64le > glibc-debuginfo-2.40-28.fc41.ppc64le > glibc-debugsource-2.40-28.fc41.ppc64le > ~/GDB/latest_gdb/print$ > > > I execute additional program to check behaviour in both the machine > > $] cat test_print_map.c > #include > > int main(void) { > printf("Hello World!\n"); > > // Print address of printf and its ieee128 variant > printf("Address of printf: %p\n", (void*)printf); > #ifdef __GLIBC__ > extern int __printfieee128(const char *, ...); > printf("Address of __printfieee128: %p\n", (void*)__printfieee128); > #endif > > return 0; > } > > Compilation > gcc -O0 -g -o test_print_map test_print_map.c --no-builtin > > > Machine 2 (with glibc 2.40) > $ ./test_printf_map > Hello World! > Address of printf: 0x7fff806870c0 <---- Same address > Address of __printfieee128: 0x7fff806870c0 <------ Same address > Abhay@ltcd97-lp3:~/GDB/latest_gdb/print$ > > > Machine1 (with glibc 2.34) > $ ./test_printf_map > Hello World! > Address of printf: 0x20002a066980 <-------- Different address > Address of __printfieee128: 0x20002a082e80 <-------- Different address > [abhay@kubota print]$ > > > Based on above output, my assumption are (may be it is not 100% true): > Here, the compiler + linker decide how to bind the symbol: > > In glibc 2.40 : > printf is just a strong alias to __printfieee128, so both resolve to the > same address at link time. > > In glibc 2.34 : > printf lives at a different symbol table entry than __printfieee128. > May be two different definitions or pointing to IO_printf(). I am not sure. > > > So the query is why gdb is not able to stop at printf symbol where glibc > 2.40 is installed ? Is this a bug in glibc or I am missing something ? > > > Regards: > Sachin. There is actually a GLIBC bugzilla about this and it's not just printf, but all IEEE 128-bit floating point functions. I've assigned it to you now! :-) I don't remember if the solution in Carl's last comment was actually decided to be the correct way to "fix" this though: https://sourceware.org/bugzilla/show_bug.cgi?id=29989 My guess is the difference between your two systems, is that the newer system's gcc was built with --with-long-double-format=ieee which causes gcc to enable -mabi=ieeelongdouble by default, meaning "long double" is equal to IEEE128 instead of the older -mabi=ibmlongdouble usage, where "long double" is equal to the IBM128/IBM double-double format. With -mabi=ibmlongdouble, calls to printf() are directed at the printf symbol in glibc. With -mabi=ieeelongdouble, gcc remaps printf() calls to the __printfieee128 symbol in glibc. I don't think symbol versioning would have helped here, since we have to handle calls to both the old and new printf symbols. I'll let Mike correct me if I'm wrong. :-) Obviously, we don't want to make users have to say "break __printfieee128" in gdb, but rather "break printf" should set breakpoints on both printf and __printfieee128. The best way to accomplish that though...I'm not sure we decided that. Ie, can we fix this in GLIBC or add a workaround in GDB? Mike, Segher, Carl, Surya or anyone else, anything else to add? Peter