incorrect interpretation of debug schema for variable location [clang11, x86(?)]

[nbriggs]

When the test cases are compiled with clang-devel (= clang-11) there are a lot of tests that "fail" as a result of reporting the variable involved being an address within the rw mapped file that is the executable instead of, for example, a global variable.

./memcheck/tests/varinfo1.stderr.diff-- declared at varinfo1.c:37
./memcheck/tests/varinfo1.stderr.diff:+ Address 0x........ is in a rw- mapped file /usr/home/briggs/freebsd_valgrind_clang11/memcheck/tests/varinfo1 segment
--
./memcheck/tests/varinfo1.stderr.diff-- a global variable declared at varinfo1.c:39
./memcheck/tests/varinfo1.stderr.diff:+ Address 0x........ is in a rw- mapped file /usr/home/briggs/freebsd_valgrind_clang11/memcheck/tests/varinfo1 segment
--
./memcheck/tests/varinfo1.stderr.diff-- a global variable declared at varinfo1.c:41
./memcheck/tests/varinfo1.stderr.diff:+ Address 0x........ is in a rw- mapped file /usr/home/briggs/freebsd_valgrind_clang11/memcheck/tests/varinfo1 segment
./memcheck/tests/varinfo3.stderr.diff-- a global variable declared at varinfo3.c:35
./memcheck/tests/varinfo3.stderr.diff:+ Address 0x........ is in a rw- mapped file /usr/home/briggs/freebsd_valgrind_clang11/memcheck/tests/varinfo3 segment
--
./memcheck/tests/varinfo3.stderr.diff-- a global variable declared at varinfo3.c:36
./memcheck/tests/varinfo3.stderr.diff:+ Address 0x........ is in a rw- mapped file /usr/home/briggs/freebsd_valgrind_clang11/memcheck/tests/varinfo3 segment
--
./memcheck/tests/varinfo3.stderr.diff-- a global variable declared at varinfo3.c:37
./memcheck/tests/varinfo3.stderr.diff:+ Address 0x........ is in a rw- mapped file /usr/home/briggs/freebsd_valgrind_clang11/memcheck/tests/varinfo3 segment
--
./memcheck/tests/varinfo3.stderr.diff-- a global variable declared at varinfo3.c:38
./memcheck/tests/varinfo3.stderr.diff:+ Address 0x........ is in a rw- mapped file /usr/home/briggs/freebsd_valgrind_clang11/memcheck/tests/varinfo3 segment
--
./memcheck/tests/varinfo3.stderr.diff-- Address 0x........ is 5 bytes inside data symbol "static_local_def.XXXX"
./memcheck/tests/varinfo3.stderr.diff:+ Address 0x........ is in a rw- mapped file /usr/home/briggs/freebsd_valgrind_clang11/memcheck/tests/varinfo3 segment
--

[paulfloyd]

Back from holidays.

This is quite similar to what I see with FreeBSD 13. Before my hols I did start looking at tools to dump the dwarf debuginfo. Next I need to look more at the Valgrind code that reads the debuginfo - I presume that this is where the problem is rather than in the memcheck code that looks up the source info when an error is detected.

Unfortunately it seems that dwarf is a fairly lax standard and has a tendency to have dialects (or "vendor extensions") like GCC+GDB and clang+lldb. Valgrind is in the former camp and we're in the latter.

[nbriggs]

Hope your holidays were great. Still in near lockdown here.

llvm-dwarfdump should show the necessary debuginfo, shouldn't it?

I don't have a FreeBSD-13 installed, but your comment makes me wonder if FreeBSD-13 advanced to clang-10 or clang-11 as the default compiler.

The odd thing is that, for me, this is a clang-9 to clang-11 difference rather than a gcc to clang difference, though it could easily be clang-11 moving further away from the gcc DWARF usage than clang-9.

I picked on one particular case -- global_u1 in varinfo1 and dumped the info -- the only difference except for offsets is:

<                 DW_AT_external    (0x01)
---
>                 DW_AT_external    (true)

[paulfloyd]

clang-10 is the default on FreeBSD 13. I suspect also that clang-8 generated dwarf 2 by default whilst clang-10 generates dwarf 4. clang-11 seesm to have added some GCC extensions.

[paulfloyd]

It turns out this isn't debuginfo related. It's more to do with changes to and handling of Elf segments.

Workaround fix is https://github.com/paulfloyd/freebsd_valgrind/commit/d78c85a5058ffbf080e5099d092e779cb013c9e2

I'm still working on getting a clean fix.

On FreeBSD 13 (from 20200702, a bit old) I've gone from 66 fails to 22, and some of the varinfo ones are just trivial diffs that will pass with a bit of filtering.

[nbriggs]

I've moved on to FreeBSD 12.2-RELEASE, which appears to have advanced to clang 10 as the default:

clang --verbose --version
FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
Target: i386-unknown-freebsd12.2
Thread model: posix
InstalledDir: /usr/bin

I've rerun the regression tests with this fix included and I agree that it fixes the varinfo problems.

I've got clang8, clang10(default) and clang12 (from llvm-devel-12.0.d20201027) currently installed. Overall I'm not getting as good results as you on the number of failures--

clang10-20201117-1005.out:== 669 tests, 60 stderr failures, 4 stdout failures, 2 stderrB failures, 0 stdoutB failures, 0 post failures ==
clang12-20201117-1005.out:== 669 tests, 61 stderr failures, 5 stdout failures, 2 stderrB failures, 0 stdoutB failures, 0 post failures ==
clang8-20201117-1005.out:== 669 tests, 60 stderr failures, 4 stdout failures, 2 stderrB failures, 0 stdoutB failures, 0 post failures ==

[paulfloyd]

The fails that I get on my last run of 12.2 i386 were

== 672 tests, 27 stderr failures, 4 stdout failures, 1 stderrB failure, 0 stdoutB failures, 0 post failures ==

gdbserver_tests/mcblocklistsearch (stderrB) memcheck/tests/clientperm (stderr) memcheck/tests/descr_belowsp (stderr) memcheck/tests/dw4 (stderr) memcheck/tests/gone_abrt_xml (stderr) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/lks (stderr) memcheck/tests/manuel1 (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) helgrind/tests/tls_threads (stderr) drd/tests/annotate_smart_pointer (stderr) drd/tests/annotate_trace_memory (stderr) drd/tests/annotate_trace_memory_xml (stderr) drd/tests/dlopen (stdout) drd/tests/dlopen (stderr) drd/tests/omp_matinv (stdout) drd/tests/omp_matinv (stderr) drd/tests/omp_matinv_racy (stdout) drd/tests/omp_matinv_racy (stderr) drd/tests/omp_prime_racy (stderr) drd/tests/omp_printf (stderr) drd/tests/sigalrm (stderr) none/tests/manythreads (stdout) none/tests/manythreads (stderr) none/tests/pth_self_kill_15_other (stderr)

I was getting a lot of failures in the gdb tests on my main machine (that upgraded from 12.1 rather than a clean install) because ld.so was older than one of its source files. I fixed that by doing a touch on the source file. That's similar to what I was getting with 12.1 i386. There are 2 new fails: memcheck/tests/varinfo2 and drd/tests/omp_printf .

[nbriggs]

I rebooted my machine again, and things started to work better (it was also a 12.1 upgrade rather than clean install) -- I'm now at

== 669 tests, 27 stderr failures, 4 stdout failures, 2 stderrB failures, 0 stdoutB failures, 0 post failures ==

with the default clang compiler, and the only difference is that I also have:

gdbserver_tests/mcinfcallWSRU (stderrB)

where the differences are all of the form:

 [Switching to thread 2 (Thread ....)]
-#0  0x........ in syscall ...
+#0  0x........ in _select () from /lib/libc.so.7
 Could not write register  "xxx"; remote failure reply 'E.

[paulfloyd]

I'll check that this testcase is running correctly here.

The line of difference that you are seeing ought to be filtered by filter_gdb. I don't see a pattern that would match a single leading underscore (no underscore, double underscore and dot double underscore are all there).

[paulfloyd]

I get (in the unfiltered)

(gdb) [Switching to thread 2 (Thread 100980)]
#0  _select () at _select.S:3
3       _select.S: No such file or directory.
(gdb) Could not write register "esp"; remote failure reply 'E.

(I have the source and debug packages installed, which might be the difference).