Bug 473974

Summary: aspacem output for file segments wrong with clang 14
Product: [Developer tools] valgrind Reporter: Paul Floyd <pjfloyd>
Component: generalAssignee: Julian Seward <jseward>
Status: RESOLVED NOT A BUG    
Severity: minor    
Priority: NOR    
Version First Reported In: 3.22 GIT   
Target Milestone: ---   
Platform: Compiled Sources   
OS: FreeBSD   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Paul Floyd 2023-08-31 05:35:14 UTC
File segements get output with

         VG_(debugLog)(
            logLevel, "aspacem",
            "%3d: %s %010lx-%010lx %s %c%c%c%c%c d=0x%03llx "
            "i=%-7llu o=%-7lld (%d,%d)\n",
            segNo, show_SegKind(seg->kind),
            seg->start, seg->end, len_buf,
            seg->hasR ? 'r' : '-', seg->hasW ? 'w' : '-', 
            seg->hasX ? 'x' : '-', seg->hasT ? 'T' : '-', 
            seg->isCH ? 'H' : '-',
            seg->dev, seg->ino, seg->offset,
            ML_(am_segname_get_seqnr)(seg->fnIdx), seg->fnIdx
         );

The component for the device is 

d=0x%03llx

which is a long with width 3 and zero padding.

clang14 produces
--PID:1: aspacem   1: file 0000108000-0000108fff    4096 r---- d=0x28a8dde4190bc5c i=1050513 o=0       (1,73)
with a width of 15 that looks wrong

whilst clang16 produces
--PID:1: aspacem   1: file 0000108000-0000108fff    4096 r---- d=0x05a i=801704  o=0       (1,61)
with a width of 3 that looks right
Comment 1 Paul Floyd 2023-08-31 12:44:22 UTC
I also get 3 digits with RHEL 7.9 / GCC 11.2
Comment 2 Paul Floyd 2023-08-31 18:59:35 UTC
I think this is just a ZFS thing and it generates huge numbers, around 56 to 60 bits worth.