Re: [PATCH 11/11] explicitly test for stderr in gdb.base/dprintf.exp

[Pedro Alves <pedro@palves.net>]

On 2022-03-31 14:44, Bruno Larsen wrote:
> On 3/2/22 13:50, Pedro Alves wrote:
>> 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".
> 
> Ok, I'll try to be more explicit.
> 
>>
>>> 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?
> 
> I think it might be because of external debug information. if I run the test with debuginfod, I get the same output as you:


I don't have debuginfo enabled, in fact I don't even have it compiled into gdb:

 (gdb) set debuginfod enabled off
 Support for debuginfod is not compiled into GDB.

However, that's a hint -- it's really something similar.  I had:

 set debug-file-directory /usr/lib/debug

in my ~/.gdbinit, and the GDB I was using wasn't automatically picking that debug dir.  So
when I run the test via dejagnu, GDB is started with -nx, and I saw the failure, because
then I had no debug info for libc.  When I run GDB manually (without -nx), I have debug info
due to the debug-file-directory setting, and I can print stderr.

Doh!