public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: Bruno Larsen <blarsen@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 11/11] explicitly test for stderr in gdb.base/dprintf.exp
Date: Wed, 2 Mar 2022 16:50:50 +0000	[thread overview]
Message-ID: <22373b29-cda4-2246-edbf-8330ea67bc40@palves.net> (raw)
In-Reply-To: <20220126195053.69559-12-blarsen@redhat.com>

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
>  


  reply	other threads:[~2022-03-02 16:50 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-26 19:50 [PATCH 00/11] gdb/testsuite: Cleanup gdb.base for clang testing Bruno Larsen
2022-01-26 19:50 ` [PATCH 01/11] change gdb.base/skip.exp to use finish instead of step Bruno Larsen
2022-02-25 17:00   ` Andrew Burgess
2022-03-02 16:11   ` Pedro Alves
2022-03-02 16:39     ` Andrew Burgess
2022-03-07 19:59       ` Bruno Larsen
2022-01-26 19:50 ` [PATCH 02/11] change gdb.base/symbol-alias to xfail with clang Bruno Larsen
2022-01-26 19:50 ` [PATCH 03/11] Change gdb.base/skip-solib.exp deal with lack of epilogue information Bruno Larsen
2022-03-02 16:17   ` Pedro Alves
2022-03-07 19:53     ` Bruno Larsen
2022-01-26 19:50 ` [PATCH 04/11] change gdb.base/nodebug.c to not fail with clang Bruno Larsen
2022-01-26 19:50 ` [PATCH 05/11] update gdb.base/info-program.exp " Bruno Larsen
2022-01-26 19:50 ` [PATCH 06/11] fix gdb.base/access-mem-running.exp for clang testing Bruno Larsen
2022-01-26 19:50 ` [PATCH 07/11] fix gdb.base/call-ar-st to work with clang Bruno Larsen
2022-03-02 18:59   ` Pedro Alves
2022-03-04 14:14     ` Tom Tromey
2022-03-07 20:39     ` Bruno Larsen
2022-01-26 19:50 ` [PATCH 08/11] add xfails to gdb.base/complex-parts.exp when testing " Bruno Larsen
2022-03-02 19:10   ` Pedro Alves
2022-01-26 19:50 ` [PATCH 09/11] gdb/testsuite: don't test gdb.base/msym-bp-shl " Bruno Larsen
2022-03-02 19:33   ` Pedro Alves
2022-03-08 12:58     ` Bruno Larsen
2022-03-30 12:19     ` Bruno Larsen
2022-03-31 18:49       ` Pedro Alves
2022-03-31 19:13         ` Bruno Larsen
2022-01-26 19:50 ` [PATCH 10/11] make use of finish to leave function in gdb.base/skip-inline.exp Bruno Larsen
2022-01-26 19:50 ` [PATCH 11/11] explicitly test for stderr in gdb.base/dprintf.exp Bruno Larsen
2022-03-02 16:50   ` Pedro Alves [this message]
2022-03-31 13:44     ` Bruno Larsen
2022-03-31 14:31       ` Pedro Alves
2022-02-09 12:03 ` [PING][PATCH 00/11] gdb/testsuite: Cleanup gdb.base for clang testing Bruno Larsen
2022-02-21 12:53   ` [PINGv2][PATCH " Bruno Larsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=22373b29-cda4-2246-edbf-8330ea67bc40@palves.net \
    --to=pedro@palves.net \
    --cc=blarsen@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).