From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by sourceware.org (Postfix) with ESMTPS id 893F0385800A for ; Wed, 2 Mar 2022 16:50:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 893F0385800A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f44.google.com with SMTP id p4so1531948wmg.1 for ; Wed, 02 Mar 2022 08:50:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=ldUAol6XpEkettgfmlfg+6HrLH3yKtcr4U+J2BqE9rg=; b=Fy6gBM114mxPBBBq9FRHEv0TeTBtkE9XDnywIG43RJe2stYnAckdbC9aNR00gzpAxn vI0GIYUDhDhPdWKISboAX2GWnQhXsYU4DQdtAP4a8vXaA6kBCpv+684R9sh7ojryiSaN xIDLr+0GK+tBKAdKaClgw1t/2MRI5sD3PjIqtTZxf/hZVZHVrCCKDgY8HCxsCwRtfbRw trkF74JztW+ii/Ft1O5k6e6z7gO00eguqpPUsbk97MmoHLkMSLUnntz+f/+K1TRAUbaW D81kgA1gjuGIW/3kapbtx/Icc7cc6w3/qsbf38C1J/3SRAZEtBaHOe8razb/LsIw0h2J 03KA== X-Gm-Message-State: AOAM531K7G+YqqJuZgjcB9mbOPABQnw5JN1rec6bxEYR7sPcgCWb4d1S pX+39/YWAbKFuSvAXd2YGI8= X-Google-Smtp-Source: ABdhPJysjVL4ssVPjtg8vxuUON5sKbdlqBWDKOPxA2dOLUel3gZa/FtatCpO+o/5Xqqd+nmqvpIz9g== X-Received: by 2002:a05:600c:1c8d:b0:381:6280:43f with SMTP id k13-20020a05600c1c8d00b003816280043fmr547428wms.111.1646239852503; Wed, 02 Mar 2022 08:50:52 -0800 (PST) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id i15-20020a05600011cf00b001edc2966dd4sm16903236wrx.47.2022.03.02.08.50.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Mar 2022 08:50:51 -0800 (PST) Message-ID: <22373b29-cda4-2246-edbf-8330ea67bc40@palves.net> Date: Wed, 2 Mar 2022 16:50:50 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH 11/11] explicitly test for stderr in gdb.base/dprintf.exp Content-Language: en-US To: Bruno Larsen , gdb-patches@sourceware.org References: <20220126195053.69559-1-blarsen@redhat.com> <20220126195053.69559-12-blarsen@redhat.com> From: Pedro Alves In-Reply-To: <20220126195053.69559-12-blarsen@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2022 16:50:55 -0000 On 2022-01-26 19:50, Bruno Larsen via Gdb-patches wrote: > Not all compilers explicitly add stderr information when compiling a It helps if you say "debug information" instead of just "information". > program, so to avoid an unrelated failure, we explicitly test to see if > the compiler has added information about it at all. This was done > thinking specifically about clang, since it doesn't add stderr > information and developers treat it as a feature. Please include a snippet of the failure in the commit log. I ran the test locally against clang, and I do see a failure here too: (gdb) PASS: gdb.base/dprintf.exp: call: fprintf: set dprintf style to call continue Continuing. kickoff 1234 also to stderr 1234 'stderr' has unknown type; cast it to its declared type (gdb) FAIL: gdb.base/dprintf.exp: call: fprintf: 1st dprintf (timeout) However, when I debug the program manually, I see that gdb is able to print stderr, if you run to main first: (gdb) p stderr 'stderr' has unknown type; cast it to its declared type (gdb) start Temporary breakpoint 1 at 0x4011f6: file ../../../src/gdb/testsuite/gdb.base/dprintf.c, line 35. Starting program: /home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.base/dprintf/dprintf Temporary breakpoint 1, main (argc=1, argv=0x7fffffffdc18) at ../../../src/gdb/testsuite/gdb.base/dprintf.c:35 35 int loc = 1234; (gdb) p stderr $1 = (FILE *) 0x7ffff7e4e5c0 <_IO_2_1_stderr_> So... it doesn't seem like the premise of the patch is correct, for the testcase runs to main -- see the "restart" call in the context of your patch, just below. Seems like something else may be going on? Why is GDB not finding the debug info for stderr in the dprintf call, while manually it is able to find it? Pedro Alves > --- > gdb/testsuite/gdb.base/dprintf.exp | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/gdb/testsuite/gdb.base/dprintf.exp b/gdb/testsuite/gdb.base/dprintf.exp > index 0b209c02a62..e214531f6dc 100644 > --- a/gdb/testsuite/gdb.base/dprintf.exp > +++ b/gdb/testsuite/gdb.base/dprintf.exp > @@ -111,6 +111,16 @@ proc test_call {} { > test_dprintf "At foo entry.*arg=1235, g=2222\r\n" "2nd dprintf" > } > > + gdb_test_multiple "print stderr" "stderr symbol check" { > + -re "\\'stderr\\' has unknown type.*" { > + untested "No information available for stderr, exiting early" > + return > + } > + -re "\\\$1.*" { > + pass "stderr is available" > + } > + } > + > with_test_prefix "fprintf" { > restart >