From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6Vx3Ag5j3WjRbhsAWB0awg (envelope-from ) for ; Wed, 01 Oct 2025 13:21:18 -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=wNG0oIBt; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 05EE91E0B6; Wed, 01 Oct 2025 13:21:18 -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 268E11E047 for ; Wed, 01 Oct 2025 13:21:14 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AADD23858409 for ; Wed, 1 Oct 2025 17:21:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AADD23858409 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1759339273; bh=U/gdnwy/lovfMzlTDCRAgs5HhWqJdzq1kONtd4lJf6g=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=wNG0oIBtXkfYx7GZRQeguT9iP38c1tmwuXyNHiWnEecQLn8l+dUdt+QdimTzY8vQi PK4q/Qdj8n3jOnixO+YeEE1K8SvyFlvRRxenwIdV+zxhHI+6OgPSYL3KyElIqiA+G9 trBIuw7wzDOqlnF7VTnhN6363JZpIOMZmoOIu29o= Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 36E653858D35 for ; Wed, 1 Oct 2025 17:20:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 36E653858D35 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 36E653858D35 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1759339217; cv=none; b=u7IoZAXG47wL7koOOqYs8QGsrnUZgNz/ZmgkEIU5JhP+KiJpZSoTJqpYV1UMlo81nRS4p8G1lVXAHDfaWg442cmFguS8iP5pV6o9qR2tUbf1H044j3vYkar2GcVIo6KlHjM84dMB4nwpN+RsN14avEt94EFn7wo1aFWkMPzaML4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1759339217; c=relaxed/simple; bh=aQatt5NyNp+MwhZ+ijbmQIRmiV3jznXgPngRB1Rmkxk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Sy8Ix+f7QkUEfHX5C+jmE8GLWJXRy1xcMRUSdl0lBX0dJV9Ria4VR/QZ8DPa8tULiKd+tBEvUR5WsVArsx6Pftkq1m2r15HFNhQTTgHU7vc+V9z62PSAjSrGLMhUJ85ISmwNiqFx+0bYMmiULxjYn2Jti0hFewvo+YWLjAqRp/I= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 36E653858D35 Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-77f67ba775aso230890b3a.3 for ; Wed, 01 Oct 2025 10:20:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759339216; x=1759944016; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=U/gdnwy/lovfMzlTDCRAgs5HhWqJdzq1kONtd4lJf6g=; b=EtGKKFK5QRBDm2M7vXvtp8DB+ioanwSJS5V3IlUm/xWxinnquOK/7cVocNH8o9IMxg jpbk9BPhtLa6BXDrUIxQtHo+CUH1XIl1rAMWbw1OxsMDTieOcK3QkYq2hYVpmtgJXkg4 8gqHhzUWbC7gz/E2zVMjYk1cTt29X9Gn6TzT+J3tEgywO0p1x66bR+ODbcrYuVC83w/Q HE2JWOe0PntQQxb1URnklNqhSVTyn5vPHoOd2gVlw5IXHt0M6oSacFXRY+pycrPc4X3F qd/CWywih4sWq8v+T5T5tep8dlJVhDElgd8aUyE6oz6+wh/2UTfwRcll59xvm5J3855L P5/g== X-Forwarded-Encrypted: i=1; AJvYcCUUfcc3hwr2hSQSJDefpwqpcQTUmNKFxd5TWm6D87OCNLR5Tv2675kaNDbJk0wCs0Eq9eA=@sourceware.org X-Gm-Message-State: AOJu0YzNrxWHTBgPsdwjqATHinFd/gppD+paX++IlBgtDUZC05qoT+Dd koNdSafVt+glsX8e/ru1kTVsePfIlVrHOtHUisIUe/bIJrJHCMaIngMQ+2njs8Ik+D8= X-Gm-Gg: ASbGnctkcA/EOlhB+XohdxWpgPEKkWUZNznKnXlMtvH2FBotLCfieGmWGiSc9clixbZ eJRoyWtyq1V6UolGnmi4Os5+CYyFRtzjvsAeq0n00Oj78NINPLk+HsTdsrzIEARG9U9fT63EzNF 1H7qGqq8MK2saVewwZapbEFAzyObC7jxllBHg28wl2RjPCO1lfz2Ekyp6HA90QC9h8Tc6oV73e6 SK/Ovbn7vnYQPgjKopb+Uas6xK3Kn0aHBZzzFWiSLxpr3fXij+59DjfQVVcZQkwDPHPPnet/bwa Jya4SoSUofX7xh6MBvNhKnQchbxQEEhv4UYd45Gv3O4jIzw9UVPOuC79TVe6dmu+WDDSJspPLU8 gfsl+JkQ4JmoR1RLQEiFph4WaDNLb1gcs6MYdkWayyRO4t68k3nUzgz1zvSowu+pY4S2xdgqxw0 Zie0eMa13c/1CBt45OlmN5v0njE9o+OoYNFEE2x4WLhPSODvGKrdoAZw== X-Google-Smtp-Source: AGHT+IHbqNTc5yDo66ug8p59F6gPgT2WTyUgsET5b9UW2Rdn0Krf+q8yS1xWsffRw//AQ9K0fllwIg== X-Received: by 2002:a05:6a00:22cb:b0:782:9b8d:24ac with SMTP id d2e1a72fcca58-78af420998bmr4791905b3a.28.1759339215871; Wed, 01 Oct 2025 10:20:15 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c3:81b5:fddf:1aa6:6ad1:8cee? ([2804:1b3:a7c3:81b5:fddf:1aa6:6ad1:8cee]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-78b02053b84sm225223b3a.53.2025.10.01.10.20.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Oct 2025 10:20:15 -0700 (PDT) Message-ID: <0535055f-7a42-4390-b134-34b8e3ee657e@linaro.org> Date: Wed, 1 Oct 2025 14:20:11 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: gdb does not stop at printf for ppc To: Peter Bergner , Sachin Monga , libc-help@sourceware.org, "libc-alpha@sourceware.org" , gdb@sourceware.org Cc: Segher Boessenkool , Michael Meissner , Surya Kumari Jangala , Carl Love References: Content-Language: en-US Organization: Linaro 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: Adhemerval Zanella Netto via Gdb Reply-To: Adhemerval Zanella Netto Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 01/10/25 01:03, Peter Bergner via Libc-help wrote: > 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 This is not only an issue for IBM float128 support, but rather for other places that we use asm alias (for instance 64 bit time support on some 32 bits abis, fortify support for some symbols that route to _chk variants, etc.). And I think Carl's suggestion might work [1], with the following: --- diff --git a/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c b/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c index 7b1640ceac..d567d98c68 100644 --- a/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c +++ b/sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c @@ -33,3 +33,6 @@ ___ieee128_printf (const char *format, ...) return done; } strong_alias (___ieee128_printf, __printfieee128) + +asm (".local printf\n" + ".set printf, __printfieee128"); --- Breaking point at printf does work: --- $ cat printf.c #include int main (int argc, char *argv[]) { printf ("%La\n", 1.2345L); } $ powerpc64le-glibc-linux-gnu-gcc -mabi=ieeelongdouble printf.c -o printf $ gdb -ex 'set breakpoint pending on' -ex 'b printf' -ex 'r' ./tst-printf-ieeelongdouble [...] Breakpoint 1.2, 0x00007ffff7c92528 in ___ieee128_printf (format=format@entry=0x100000d88 "%La\n") at ../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c:24 24 { --- I don't think we have a better solution, attribute (alias) requires the target symbol to be pre-defined (which would require to reestructure how the long double alias as done); nor I think the compiler will be able to easy synthesize it because afaiu this need to done at the TU of the alternative implementation. Do we have the concept of symbol aliases for DWARF? [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29989#c4