Re: [PATCH v4 12/15] [gdb/testsuite]: fix gdb.base/jit-elf.exp when testing with clang

[Andrew Burgess <aburgess@redhat.com>]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> When using clang as the compiler for the target, gdb.base/jit-elf.exp
> was failing with the following output:
>
>        (gdb) attach 3674146
>        Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3674146
>        Reading symbols from /lib64/libm.so.6...
>        Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
>        (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
>        Reading symbols from /lib64/libc.so.6...
>        (No debugging symbols found in /lib64/libc.so.6)
>        Reading symbols from /lib64/ld-linux-x86-64.so.2...
>        [Thread debugging using libthread_db enabled]
>        Using host libthread_db library "/lib64/libthread_db.so.1".
>        0x00000000004013ff in main (argc=3, argv=0x7fffffffd820) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
>        118|  WAIT_FOR_GDB; i = 0;  /* gdb break here 1 */
>        (gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
>
> While gcc's output is as follows:
>
>        (gdb) attach 3592961
>        Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3592961
>        Reading symbols from /lib64/libm.so.6...
>        Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
>        (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
>        Reading symbols from /lib64/libc.so.6...
>        (No debugging symbols found in /lib64/libc.so.6)
>        Reading symbols from /lib64/ld-linux-x86-64.so.2...
>        [Thread debugging using libthread_db enabled]
>        Using host libthread_db library "/lib64/libthread_db.so.1".
>        main (argc=3, argv=0x7fffffffd860) at /home/blarsen/Documents/gdb-build/gdb/testsuite/../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
>        118|  WAIT_FOR_GDB; i = 0;  /* gdb break here 1 */
>        (gdb) PASS: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
>
> Clang-compiled code is clearly working, as gdb is attaching and running
> to the established breakpoint.

I think it would be helpful if you could point out exactly what _is_
causing the failure, see below for why...

>                                To fix the false positive, the regexp for
> checking where gdb has stopped was relaxed a little, to allow for the
> address at the start of the line, and to allow the relative path.
> ---
>  gdb/testsuite/gdb.base/jit-elf.exp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gdb/testsuite/gdb.base/jit-elf.exp b/gdb/testsuite/gdb.base/jit-elf.exp
> index 38d541f74b9..0f296dfd579 100644
> --- a/gdb/testsuite/gdb.base/jit-elf.exp
> +++ b/gdb/testsuite/gdb.base/jit-elf.exp
> @@ -54,7 +54,7 @@ proc clean_reattach {} {
>      clean_restart ${main_binfile}
>  
>      if { ![gdb_attach $testpid \
> -	      -pattern "main.*at .*$::main_srcfile:.*"] } {
> +	      -pattern ".*main.*at .*$::main_basename.c:.*"] } {

... when I run this test using Clang (9.0.1) _without_ this patch, the
test passes.  I notice that when you ran the test the source file
reported at the breakpoint doesn't include the ${srcdir}.

I don't know why you're only seeing a relative path, but I guess, as far
as this test is concerned, just checking for the final filename is fine.

I don't think the change to add the leading '.*' is needed though.  The
pattern is never anchored to the start of a line, so expect will happily
skip any leading content when looking for a match, the extra '.*' is
just unnecessary noise.

Thanks,
Andrew

>  	return 0
>      }
>  
> -- 
> 2.31.1