Re: [Valgrind-developers] [valgrind] Rewrite DWARF inlined subroutine handling to work cross CU

[Paul F. <pj...@wa...>]

On 6/20/25 11:54, Mark Wielaard wrote:
> Which failures are those? Are they all about std_list or also other
> objects? Which compiler version was used?

The failures are

memcheck/tests/leak-autofreepool-5       (stderr)
memcheck/tests/leak_cpp_interior         (stderr)
helgrind/tests/shared_timed_mutex        (stderr)
drd/tests/annotate_static                (stderr)
drd/tests/monitor_example                (stderr)
drd/tests/shared_timed_mutex             (stderr)
drd/tests/std_list                       (stderr)
drd/tests/timed_mutex                    (stderr)

They are all C++ tests apart from the first.

Compiler is the system compiler, based on LLVM 18


paulf> clang++ --version
FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git 
llvmorg-18.1.6-0-g1118c
2e05e67)
Target: x86_64-unknown-freebsd14.2
Thread model: posix
InstalledDir: /usr/bin

> Could you upload/sent the readelf --debug-dump=info drd/tests/std_list
> output somewhere? Probably gzipped.

I'll e-mail them to you directly.

> The Warning says there is a DW_TAG_subprogram that has no name and no
> reference to another subprogram that could describe it. Which means the
> subprogram is not very useful. I wonder why. Maybe a bug in the
> compiler? Or an artificial function without a name?

Pass.

> Were those tests run with -q? The Warning shouldn't show up then.
> Maybe we should filter out those Warning messages in some stderr
> filter?

None of the tests use -q. With -q there's no warning.

> Or maybe the Warning should be behind -v since there isn't really
> something the user can do about it, except recompile their program with
> another compiler?

We could filter, but I think that making the warning verbose only would 
be better (if there's no other fix).

A+

Paul