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

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

Hi Paul,

On Sat, Jun 21, 2025 at 05:27:43PM +0200, Paul Floyd via Valgrind-developers wrote:
> On 21/06/2025 00:12, Mark Wielaard wrote:
> >>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?
> 
> I hadn't seen that cfarm how has some FreeBSD machines. I'll see if
> I can setup a crontab for regtest on one of them.
> 
> Two seem to be unreachable at the moment. The reachable one is
> running CheriBSD. That's hardware with enhanced security built in to
> all pointers. I doubt that Valgrind will work on that (and in any
> case it is already doing much of the checks that Memcheck does but
> in hardware).
> 
> However, you shouldn't need to to that far. I can reproduce an
> example on Fedora 42 amd64.
> 
> In the drd/tests directory, compile std_list.cpp with everything LLVM:
> 
> clang++ -g -o std_list std_list.cpp -fuse-ld=/usr/bin/ld.lld -stdlib=libc++
> 
> That is
> 
> clang++ --version
> clang version 20.1.6 (Fedora 20.1.6-1.fc42)
> 
> Then I can reproduce the problem:
> 
> ../../vg-in-place --tool=drd --check-stack-var=yes --show-confl-seg
> =no ./std_list

Thanks. I did eventually install FreeBSD 14.3 in a VM. That and the
above showed me what was going on. There are two issues with the clang
produced DWARF.

First for some artificial (DW_AT_artificial) subprograms it doesn't
produce a DW_AT_name. In that case we just call it "<artificial>".

In some other cases like:

static void func (int i)
{
  static int count = 1;
  count += i;
}

void inc (void)
{
  func (1);
}

$ clang -g -O2 -c t.c

It produces:

 <1><23>: Abbrev Number: 2 (DW_TAG_subprogram)
 <2><24>: Abbrev Number: 3 (DW_TAG_variable)
    <25>   DW_AT_name        : (indexed string: 0x3): count
    <26>   DW_AT_type        : <0x30>
    <2a>   DW_AT_decl_file   : 0
    <2b>   DW_AT_decl_line   : 3
    <2c>   DW_AT_location    : (DW_OP_addrx <0>)
 <2><2f>: Abbrev Number: 0

So it "invents" a no-attribute DW_TAG_subprogram to put the static
count variable in. Which is odd, since there is a real
DW_TAG_subprogram with a DW_AT_name for func.

We just ignore these subprograms without attributes since they are
useless.

commit 116a1c8242891b5ddcd1ce9704b0ab90143cc968
Author: Mark Wielaard <ma...@kl...>
Date:   Sat Jun 21 23:04:04 2025 +0200

    Update DW_TAG_subprogram parsing for clang
    
    Clang doesn't give a name for some artificial subprograms. In that
    case just use "<artificial>" as the name of the DW_TAG_subprogram.
    
    Clang also sometimes generates a DW_TAG_subprogram without any
    attributes. These aren't really useful for us. So just silently skip
    them.
    
    If we warn about subprograms without a name, specification or abstract
    origin, also emit the index in the .debug_info section to make it
    easier to look them up.

Hopefully that gets rid of all the Warnings.

Cheers,

Mark