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

[Mark W. <ma...@kl...>]

Hi Paul,

On Fri, Jun 20, 2025 at 08:20:16PM +0200, Paul Floyd via Valgrind-developers wrote:
> 
> 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.

Could you sent me the log or diff files of the above tests?

> 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

I'll try to get a freebsd 14.2 setup. It looks like the cfarm only has
freebsd 15, do you happen to know if the issue also occurs on that
version?

> >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.

Thanks, I looked them over but I don't see where the issue is. I will
have to try to replicate myself on a freebsd system.

> >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.

OK. Maybe we can run these tests with -q. I'll look.
 
> >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).

Yeah, if we cannot figure it out then hiding behind -v might be best.

Thanks,

Mark