[Bug debug/103241] New: Odd 0 length entries in location lists

[Bug debug/103241] New: Odd 0 length entries in location lists

[wcohen at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

            Bug ID: 103241
           Summary: Odd 0 length entries in location lists
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wcohen at redhat dot com
  Target Milestone: ---

I wrote a dwgrep (https://pmachata.github.io/dwgrep/) script to examine the
location lists of function parameters of the kernel and print out each function
and parameter that had zero length entries in the location lists:

  dwgrep /usr/lib/debug/lib/modules/5.14.15-200.fc34.x86_64/vmlinux -e '
let A := entry (?TAG_subprogram) (?AT_ranges || ?AT_low_pc);
let FSTART := (A ?AT_ranges @AT_ranges low) || ( A low);
let PARM := A child ?TAG_formal_parameter;
(PARM ?AT_location @AT_location address length==0) ([A name, FSTART, PARM
name])' | grep \\[ | more

Some of the functions in the kernel that were flagged may have been confused by
the constant propagation, irsa, or partial inlining optimization.  However,
There were some functions parameters that included entries with 0 length
entries in the location list for the parameter.  Focusing on one function,
static_protections:

["static_protections", 0xffffffff8107a540, "prot"]
["static_protections", 0xffffffff8107a540, "start"]
["static_protections", 0xffffffff8107a540, "pfn"]
["static_protections", 0xffffffff8107a540, "npg"]
["static_protections", 0xffffffff8107a540, "warnlvl"]


Using The following to look at the section of the debuginfo associated with the
function:

llvm-dwarfdump -c --name="static_protection"
/usr/lib/debug/lib/modules/5.14.15-200.fc34.x86_64/vmlinux | more

See the following for static_protection where first entry for "prot" parameter
is 0 length and overlaps the next entry:

0x00e44d5c:   DW_TAG_formal_parameter
                DW_AT_abstract_origin   (0x00e3fb6d "prot")
                DW_AT_location  (0x002c83db: 
                   [0xffffffff8107a540, 0xffffffff8107a540): DW_OP_reg5 RDI
                   [0xffffffff8107a540, 0xffffffff8107a569): DW_OP_reg5 RDI,
DW_OP_piece 0x8
                   [0xffffffff8107a5a0, 0xffffffff8107a5f3): DW_OP_reg5 RDI
                   [0xffffffff8107a617, 0xffffffff8107a65b): DW_OP_reg3 RBX
                   [0xffffffff8107a66a, 0xffffffff8107a67e): DW_OP_reg3 RBX,
DW_OP_piece 0x8
                   [0xffffffff8107a67e, 0xffffffff8107a68c): DW_OP_reg5 RDI
                   [0xffffffff8107a68c, 0xffffffff8107a6a1): DW_OP_reg3 RBX,
DW_OP_piece 0x8
                   [0xffffffff8107a6a1, 0xffffffff8107a6a1): DW_OP_reg3 RBX,
DW_OP_piece 0x8
                   [0xffffffff8107a6a1, 0xffffffff8107a6cb): DW_OP_reg3 RBX
                   [0xffffffff8107a6cb, 0xffffffff8107a6cb): DW_OP_reg3 RBX,
DW_OP_piece 0x8
                   [0xffffffff81bc6967, 0xffffffff81bc6994): DW_OP_reg3 RBX,
DW_OP_piece 0x8
                   [0xffffffff81bc69b5, 0xffffffff81bc6a24): DW_OP_reg3 RBX,
DW_OP_piece 0x8)
                DW_AT_unknown_2137      (0x002c83c3)

0x00e44d69:   DW_TAG_formal_parameter
                DW_AT_abstract_origin   (0x00e3fb7a "start")
                DW_AT_location  (0x002c84ed: 
                   [0xffffffff8107a540, 0xffffffff8107a5a0): DW_OP_reg4 RSI
                   [0xffffffff8107a5a0, 0xffffffff8107a65b): DW_OP_reg12 R12
                   [0xffffffff8107a65b, 0xffffffff8107a66a):
DW_OP_GNU_entry_value(DW_OP_reg4 RSI), DW_OP_s
tack_value
                   [0xffffffff8107a66a, 0xffffffff8107a68c): DW_OP_reg4 RSI
                   [0xffffffff8107a68c, 0xffffffff8107a6cb): DW_OP_reg12 R12
                   [0xffffffff8107a6cb, 0xffffffff8107a6cb): DW_OP_reg4 RSI
                   [0xffffffff81bc6967, 0xffffffff81bc698c): DW_OP_reg4 RSI
                   [0xffffffff81bc698c, 0xffffffff81bc6a24): DW_OP_reg12 R12)
                DW_AT_unknown_2137      (0x002c84dd)

0x00e44d76:   DW_TAG_formal_parameter
                DW_AT_abstract_origin   (0x00e3fb87 "pfn")
                DW_AT_location  (0x002c85a8: 
                   [0xffffffff8107a540, 0xffffffff8107a5a0): DW_OP_reg1 RDX
                   [0xffffffff8107a5a0, 0xffffffff8107a65b): DW_OP_reg15 R15
                   [0xffffffff8107a65b, 0xffffffff8107a66a):
DW_OP_GNU_entry_value(DW_OP_reg1 RDX), DW_OP_s
tack_value
                   [0xffffffff8107a66a, 0xffffffff8107a68c): DW_OP_reg1 RDX
                   [0xffffffff8107a68c, 0xffffffff8107a6cb): DW_OP_reg15 R15
                   [0xffffffff8107a6cb, 0xffffffff8107a6cb): DW_OP_reg1 RDX
                   [0xffffffff81bc6967, 0xffffffff81bc6983): DW_OP_reg1 RDX
                   [0xffffffff81bc6983, 0xffffffff81bc6a24): DW_OP_reg15 R15)
                DW_AT_unknown_2137      (0x002c8598)

0x00e44d83:   DW_TAG_formal_parameter
                DW_AT_abstract_origin   (0x00e3fb94 "npg")
                DW_AT_location  (0x002c8663: 
                   [0xffffffff8107a540, 0xffffffff8107a5a0): DW_OP_reg2 RCX
                   [0xffffffff8107a5a0, 0xffffffff8107a65b): DW_OP_reg13 R13
                   [0xffffffff8107a65b, 0xffffffff8107a66a):
DW_OP_GNU_entry_value(DW_OP_reg2 RCX), DW_OP_s
tack_value
                   [0xffffffff8107a66a, 0xffffffff8107a68c): DW_OP_reg2 RCX
                   [0xffffffff8107a68c, 0xffffffff8107a6cb): DW_OP_reg13 R13
                   [0xffffffff8107a6cb, 0xffffffff8107a6cb): DW_OP_reg2 RCX
                   [0xffffffff81bc6967, 0xffffffff81bc6977): DW_OP_reg2 RCX
                   [0xffffffff81bc6977, 0xffffffff81bc6a24): DW_OP_reg13 R13)
                DW_AT_unknown_2137      (0x002c8653)

0x00e44d90:   DW_TAG_formal_parameter
                DW_AT_abstract_origin   (0x00e3fba1 "lpsize")
                DW_AT_location  (0x002c8718: 
                   [0xffffffff8107a540, 0xffffffff8107a585): DW_OP_reg8 R8
                   [0xffffffff8107a585, 0xffffffff8107a65b): DW_OP_reg14 R14
                   [0xffffffff8107a65b, 0xffffffff8107a66a):
DW_OP_GNU_entry_value(DW_OP_reg8 R8), DW_OP_st
ack_value
                   [0xffffffff8107a66a, 0xffffffff8107a6cb): DW_OP_reg14 R14
                   [0xffffffff81bc6967, 0xffffffff81bc6a24): DW_OP_reg14 R14)
                DW_AT_unknown_2137      (0x002c870e)

0x00e44d9d:   DW_TAG_formal_parameter
                DW_AT_abstract_origin   (0x00e3fbae "warnlvl")
                DW_AT_location  (0x002c8798: 
                   [0xffffffff8107a540, 0xffffffff8107a5a0): DW_OP_reg9 R9
                   [0xffffffff8107a5a0, 0xffffffff8107a66a): DW_OP_fbreg -72
                   [0xffffffff8107a66a, 0xffffffff8107a68c): DW_OP_reg9 R9
                   [0xffffffff8107a68c, 0xffffffff8107a6cb): DW_OP_fbreg -72
                   [0xffffffff8107a6cb, 0xffffffff8107a6cb): DW_OP_reg9 R9
                   [0xffffffff81bc6967, 0xffffffff81bc6974): DW_OP_reg9 R9
                   [0xffffffff81bc6974, 0xffffffff81bc6a24): DW_OP_fbreg -72)
                DW_AT_unknown_2137      (0x002c878a)


It looks like that first "prot" entry [0xffffffff8107a540, 0xffffffff8107a540):
DW_OP_reg5 RDI isn't useful as it is 0 length and the next entry covers its
start.  The entries for [0xffffffff8107a6cb, 0xffffffff8107a6cb) for "start",
"pfn", "lpsize", and "warnlvl" look questionable as that would be an area
outside the function's first entry [0xffffffff8107a540, 0xffffffff8107a6cb).

The source code associated with with this function
https://elixir.bootlin.com/linux/v5.14.15/source/arch/x86/mm/pat/set_memory.c#L534
has a struct being passed in and the other cases seem to also have a struct as
the parameter.

[Bug debug/103241] Odd 0 length entries in location lists

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We'd need preprocessed source + full gcc command line to investigate particular
cases, but generally, gcc itself doesn't often know that the range is zero
length, it has two labels that mark the start and end of the range.  If it is
the same labels, obviously it knows it is zero length range and can drop it,
but if it is different labels, it is harder or impossible (consider e.g. inline
asm in between, the inline asm could expand to zero instructions or zero
instructions in the current section (.pushsection, emit something elsewhere,
.popsection), or even just asm ("") - gcc intentionally doesn't try to
understand what inline asm does.

[Bug debug/103241] Odd 0 length entries in location lists

[wcohen at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

--- Comment #2 from Will Cohen <wcohen at redhat dot com> ---
Yes, the kernel vmlinux is too large and isn't a great reproducer for this.
Need a much smaller example.  Trying to compile just the
linux/arch/x86/mm/pat/set_memory.c with -save-temps to provide a better view of
what GCC is doing.  From the output of llvm-dwarfdump there seems to be two
flavors of 0-length location list entries:

-At the very beginning of the function "start" has  "[0xffffffff8107a540,
0xffffffff8107a540): DW_OP_reg5 RDI" followed by "[0xffffffff8107a540,
0xffffffff8107a569): DW_OP_reg5 RDI, DW_OP_piece 0x8"

-The function is has two regions:
                 [0xffffffff8107a540, 0xffffffff8107a6cb)
                 [0xffffffff81bc6967, 0xffffffff81bc6a24))
  A number of the arguments have 0-length location lists of the form (for
"start"):

                   [0xffffffff8107a6cb, 0xffffffff8107a6cb): DW_OP_reg4 RSI


Removed the arch/x86/mm/pat/set_memory.o file from kernel build, did a "make
V=1 > problems".  Extracted the command line and added a -save-temps:

 gcc -save-temps -Wp,-MMD,arch/x86/mm/pat/.set_memory.o.d -nostdinc
-I./arch/x86/include -I./arch/x86/include/generated  -I./include
-I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi
-I./include/generated/uapi -include ./include/linux/compiler-version.h -include
./include/linux/kconfig.h -include ./include/linux/compiler_types.h
-D__KERNEL__ -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
-Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type
-Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx
-fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387
-mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic
-mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables
-mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables
-fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation
-Wno-format-overflow -Wno-address-of-packed-member -O2
-fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector -Werror
"-Wimplicit-fallthrough=5" -Wno-main -Wno-unused-but-set-variable
-Wno-unused-const-variable -fno-stack-clash-protection -pg -mrecord-mcount
-mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wvla
-Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds
-Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized
-Wno-alloc-size-larger-than -fno-strict-overflow -fno-stack-check
-fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types
-Werror=designated-init -Wno-packed-not-aligned -g   
-DKBUILD_MODFILE='"arch/x86/mm/pat/set_memory"'
-DKBUILD_BASENAME='"set_memory"' -DKBUILD_MODNAME='"set_memory"'
-D__KBUILD_MODNAME=kmod_set_memory -c -o arch/x86/mm/pat/set_memory.o
arch/x86/mm/pat/set_memory.c  ; ./tools/objtool/objtool orc generate   --no-fp 
 --retpoline  --uaccess  arch/x86/mm/pat/set_memory.o

The set_memory.s is still pretty large, but shows what the gcc is generating
for the debuginfo.

[Bug debug/103241] Odd 0 length entries in location lists

[wcohen at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

--- Comment #3 from Will Cohen <wcohen at redhat dot com> ---
Created attachment 51812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51812&action=edit
The set_memory.s from -save-temps compilation of set_memory.c

[Bug debug/103241] Odd 0 length entries in location lists

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
Can you please attach pre-processed source file (use -E).

[Bug debug/103241] Odd 0 length entries in location lists

[wcohen at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

--- Comment #5 from Will Cohen <wcohen at redhat dot com> ---
Created attachment 51813
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51813&action=edit
set_memory.i from the gcc -save-temps build

[Bug debug/103241] Odd 0 length entries in location lists

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Will Cohen from comment #5)
> Created attachment 51813 [details]
> set_memory.i from the gcc -save-temps build

Thanks. All right, I compiled the attached source file with the option, but
can't find the suspicious range:
[0xffffffff8107a6cb, 0xffffffff8107a6cb): DW_OP_reg4 RSI

Can you please paste the suspicious range output and lines next to it?
I'm using llvm-dwarfdump version 13.

[Bug debug/103241] Odd 0 length entries in location lists

[wcohen at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

--- Comment #7 from Will Cohen <wcohen at redhat dot com> ---
Looking at the set_mem.s the second issue of the 0-length location entry for
static_protections is coming from this bit of assembly in the set_memory.s:


        .byte   0x4
        .uleb128 .LVL637-.LVL615
        .uleb128 .LHOTE19-.LVL615
        .uleb128 0x3
        .byte   0x53
        .byte   0x93
        .uleb128 0x8

The attached .s and .i files were from a local compile of linux git repo commit
8ab774587903771821b59471cc723bba6d893942.  The part of the llvm-dwarf dump
related should be looking for is [0x0000000000001b1b, 0x0000000000001b1b).

llvm-dwarfdump -c --name="static_protections" arch/x86/mm/pat/set_memory.o
|more


0x00019218: DW_TAG_subprogram
              DW_AT_abstract_origin     (0x00014236 "static_protections")
              DW_AT_ranges      (0x00000bc0
                 [0x0000000000001990, 0x0000000000001b1b)
                 [0x0000000000000000, 0x00000000000000bd))
              DW_AT_frame_base  (DW_OP_call_frame_cfa)
              DW_AT_call_all_calls      (true)
              DW_AT_sibling     (0x00019807)

0x00019228:   DW_TAG_formal_parameter
                DW_AT_abstract_origin   (0x00014248 "prot")
                DW_AT_location  (0x00006f38: 
                   [0x0000000000001990, 0x0000000000001990): DW_OP_reg5 RDI
                   [0x0000000000001990, 0x00000000000019b9): DW_OP_reg5 RDI,
DW_
OP_piece 0x8
                   [0x00000000000019f0, 0x0000000000001a43): DW_OP_reg5 RDI
                   [0x0000000000001a67, 0x0000000000001aab): DW_OP_reg3 RBX
                   [0x0000000000001ace, 0x0000000000001adc): DW_OP_reg5 RDI
                   [0x0000000000001adc, 0x0000000000001af1): DW_OP_reg3 RBX,
DW_
OP_piece 0x8
                   [0x0000000000001af1, 0x0000000000001af1): DW_OP_reg3 RBX,
DW_
OP_piece 0x8
                   [0x0000000000001af1, 0x0000000000001b1b): DW_OP_reg3 RBX
                   [0x0000000000001b1b, 0x0000000000001b1b): DW_OP_reg3 RBX,
DW_
OP_piece 0x8
                   [0x0000000000000000, 0x000000000000002d): DW_OP_reg3 RBX,
DW_
OP_piece 0x8
                   [0x000000000000004e, 0x000000000000007e): DW_OP_reg3 RBX
                   [0x000000000000007e, 0x00000000000000bd): DW_OP_reg3 RBX,
DW_
OP_piece 0x8)
                DW_AT_unknown_2137      (0x00006f20)

0x00019235:   DW_TAG_formal_parameter
                DW_AT_abstract_origin   (0x00014255 "start")
                DW_AT_location  (0x00006fb1: 
                   [0x0000000000001990, 0x00000000000019f0): DW_OP_reg4 RSI
                   [0x00000000000019f0, 0x0000000000001aab): DW_OP_reg12 R12
                   [0x0000000000001aab, 0x0000000000001aba):
DW_OP_entry_value(D
W_OP_reg4 RSI), DW_OP_stack_value
                   [0x0000000000001aba, 0x0000000000001adc): DW_OP_reg4 RSI
                   [0x0000000000001adc, 0x0000000000001b1b): DW_OP_reg12 R12
                   [0x0000000000001b1b, 0x0000000000001b1b): DW_OP_reg4 RSI
                   [0x0000000000000000, 0x0000000000000025): DW_OP_reg4 RSI
                   [0x0000000000000025, 0x00000000000000bd): DW_OP_reg12 R12)
                DW_AT_unknown_2137      (0x00006fa1)

0x00019242:   DW_TAG_formal_parameter
                DW_AT_abstract_origin   (0x00014262 "pfn")
                DW_AT_location  (0x00007009: 
                   [0x0000000000001990, 0x00000000000019f0): DW_OP_reg1 RDX
                   [0x00000000000019f0, 0x0000000000001aab): DW_OP_reg15 R15
                   [0x0000000000001aab, 0x0000000000001aba):
DW_OP_entry_value(D
W_OP_reg1 RDX), DW_OP_stack_value
                   [0x0000000000001aba, 0x0000000000001adc): DW_OP_reg1 RDX
                   [0x0000000000001adc, 0x0000000000001b1b): DW_OP_reg15 R15
                   [0x0000000000001b1b, 0x0000000000001b1b): DW_OP_reg1 RDX
                   [0x0000000000000000, 0x000000000000001c): DW_OP_reg1 RDX
                   [0x000000000000001c, 0x00000000000000bd): DW_OP_reg15 R15)
                DW_AT_unknown_2137      (0x00006ff9)

0x0001924f:   DW_TAG_formal_parameter
                DW_AT_abstract_origin   (0x0001426f "npg")
                DW_AT_location  (0x00007061: 
                   [0x0000000000001990, 0x00000000000019f0): DW_OP_reg2 RCX
                   [0x00000000000019f0, 0x0000000000001aab): DW_OP_reg13 R13
                   [0x0000000000001aab, 0x0000000000001aba):
DW_OP_entry_value(D
W_OP_reg2 RCX), DW_OP_stack_value
                   [0x0000000000001aba, 0x0000000000001adc): DW_OP_reg2 RCX
                   [0x0000000000001adc, 0x0000000000001b1b): DW_OP_reg13 R13
                   [0x0000000000001b1b, 0x0000000000001b1b): DW_OP_reg2 RCX
                   [0x0000000000000000, 0x0000000000000010): DW_OP_reg2 RCX
                   [0x0000000000000010, 0x00000000000000bd): DW_OP_reg13 R13)
                DW_AT_unknown_2137      (0x00007051)

0x0001925c:   DW_TAG_formal_parameter
                DW_AT_abstract_origin   (0x0001427c "lpsize")
                DW_AT_location  (0x000070b3: 
                   [0x0000000000001990, 0x00000000000019d5): DW_OP_reg8 R8
                   [0x00000000000019d5, 0x0000000000001aab): DW_OP_reg14 R14
                   [0x0000000000001aab, 0x0000000000001aba):
DW_OP_entry_value(D
W_OP_reg8 R8), DW_OP_stack_value
                   [0x0000000000001aba, 0x0000000000001b1b): DW_OP_reg14 R14
                   [0x0000000000000000, 0x00000000000000bd): DW_OP_reg14 R14)
                DW_AT_unknown_2137      (0x000070a9)

0x00019269:   DW_TAG_formal_parameter
                DW_AT_abstract_origin   (0x00014289 "warnlvl")
                DW_AT_location  (0x000070f4: 
                   [0x0000000000001990, 0x00000000000019f0): DW_OP_reg9 R9
                   [0x00000000000019f0, 0x0000000000001aba): DW_OP_fbreg -72
                   [0x0000000000001aba, 0x0000000000001adc): DW_OP_reg9 R9
                   [0x0000000000001adc, 0x0000000000001b1b): DW_OP_fbreg -72
                   [0x0000000000001b1b, 0x0000000000001b1b): DW_OP_reg9 R9
                   [0x0000000000000000, 0x000000000000000d): DW_OP_reg9 R9
                   [0x000000000000000d, 0x00000000000000bd): DW_OP_fbreg -72)
                DW_AT_unknown_2137      (0x000070e6)

[Bug debug/103241] Odd 0 length entries in location lists

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-11-18

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
I tried reducing that to:

$ cat set_memory.i
enum { CPA_PROTECT, CPA_DETECT } check_conflict(int warnlvl, long) {
  warnlvl || conflicts();
}
long static_protections_start;
static_protections(warnlvl) {
  check_conflict(warnlvl, static_protections_start);
  lookup_address_in_pgd(0, static_protections_start);
}
__change_page_attr_numpages;
__change_page_attr() {
  __change_page_attr_numpages = 2;
  static_protections(CPA_DETECT);
}

$ gcc set_memory.i -w -g -O2 -c && llvm-dwarfdump -c
--name="static_protections" set_memory.o | grep "0x0000000000000055,
0x0000000000000055"
                       [0x0000000000000055, 0x0000000000000055): DW_OP_reg4
RSI)

Is it an example of the error you reported?

[Bug debug/103241] Odd 0 length entries in location lists

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Isn't that just how debug location views work by design?
I bet llvm-dwarfdump doesn't understand those...
Just read https://dwarfstd.org/ShowIssue.php?issue=170427.1
or Alex' papers on the topic...

[Bug debug/103241] Odd 0 length entries in location lists

[wcohen at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

--- Comment #10 from Will Cohen <wcohen at redhat dot com> ---
That example in comment #5 at [0x0000000000000055, 0x0000000000000055) looks
different than the original example as it is referring to an argument for an
inlined function.  The function mentioned in the original description
static_protections is declared as inlined but is actually generated as an
non-inlined function.

Would https://dwarfstd.org/ShowIssue.php?issue=170427.1  apply in the original
example?  Are there actual multiple views of the parameters in the places with
0-length location list entries?

The first 0-length location list entry for prot would be 

        .byte   0x4
        .uleb128 .LVL615-.LVL615
        .uleb128 .LVL615-.LVL615
        .uleb128 0x1
        .byte   0x55

The second 0-length location list entry in the location list would be:

        .byte   0x4
        .uleb128 .LVL637-.LVL615
        .uleb128 .LHOTE19-.LVL615
        .uleb128 0x1
        .byte   0x52

[Bug debug/103241] Odd 0 length entries in location lists

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
        .byte   0x4
        .uleb128 .LVL615-.LVL615
        .uleb128 .LVL615-.LVL615
        .uleb128 0x1
        .byte   0x55

The second 0-length location list entry in the location list would be:

        .byte   0x4
        .uleb128 .LVL637-.LVL615
        .uleb128 .LHOTE19-.LVL615
        .uleb128 0x1
        .byte   0x52
Please when posting compiler output use -dA option and include a few lines
before/after so that it is clear if there is a location view entry there too or
not.

CCing Alex if he wants to add something.

[Bug debug/103241] Odd 0 length entries in location lists

[wcohen at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

--- Comment #12 from Will Cohen <wcohen at redhat dot com> ---
What is the "-dA" option?

What are the .LVUS* labels referencing in the generated set_memory.s referring
to?  They are paired up with the .LLST* labels.  From the earlier set_memory.s
that appears to be associated with prot parameter:

.LVUS627:
        .uleb128 0
        .uleb128 .LVU2887
        .uleb128 .LVU2887
        .uleb128 .LVU2895
        .uleb128 .LVU2910
        .uleb128 .LVU2939
        .uleb128 .LVU2946
        .uleb128 .LVU2974
        .uleb128 .LVU2983
        .uleb128 .LVU2987
        .uleb128 .LVU2987
        .uleb128 .LVU3000
        .uleb128 .LVU3000
        .uleb128 .LVU3004
        .uleb128 .LVU3004
        .uleb128 .LVU3016
        .uleb128 .LVU3016
        .uleb128 0
        .uleb128 0
        .uleb128 .LVU3027
        .uleb128 .LVU3029
        .uleb128 .LVU3036
        .uleb128 .LVU3036
        .uleb128 0

This looks to be the location list for prot variable from set_memory.s earlier
attached to this bug:


.LLST627:
        .byte   0x6
        .quad   .LVL615
        .byte   0x4
        .uleb128 .LVL615-.LVL615
        .uleb128 .LVL615-.LVL615
        .uleb128 0x1
        .byte   0x55
        .byte   0x4
        .uleb128 .LVL615-.LVL615
        .uleb128 .LVL616-.LVL615
        .uleb128 0x3
        .byte   0x55
        .byte   0x93
        .uleb128 0x8
        .byte   0x4
        .uleb128 .LVL619-.LVL615
        .uleb128 .LVL623-.LVL615
        .uleb128 0x1
        .byte   0x55
        .byte   0x4
        .uleb128 .LVL625-.LVL615
        .uleb128 .LVL628-.LVL615
        .uleb128 0x1
        .byte   0x53
        .byte   0x4
        .uleb128 .LVL630-.LVL615
        .uleb128 .LVL631-.LVL615
        .uleb128 0x1
        .byte   0x55
        .byte   0x4
        .uleb128 .LVL631-.LVL615
        .uleb128 .LVL634-.LVL615
        .uleb128 0x3
        .byte   0x53
        .byte   0x93
        .uleb128 0x8
        .byte   0x4
        .uleb128 .LVL634-.LVL615
        .uleb128 .LVL634-.LVL615
        .uleb128 0x3
        .byte   0x53
        .byte   0x93
        .uleb128 0x8
        .byte   0x4
        .uleb128 .LVL634-.LVL615
        .uleb128 .LVL637-.LVL615
        .uleb128 0x1
        .byte   0x53
        .byte   0x4
        .uleb128 .LVL637-.LVL615
        .uleb128 .LHOTE19-.LVL615
        .uleb128 0x3
        .byte   0x53
        .byte   0x93
        .uleb128 0x8
        .byte   0x6
        .quad   .LFSB4151
        .byte   0x4
        .uleb128 .LFSB4151-.LFSB4151
        .uleb128 .LVL642-.LFSB4151
        .uleb128 0x3
        .byte   0x53
        .byte   0x93
        .uleb128 0x8
        .byte   0x4
        .uleb128 .LVL644-.LFSB4151
        .uleb128 .LVL646-.LFSB4151
        .uleb128 0x1
        .byte   0x53
        .byte   0x4
        .uleb128 .LVL646-.LFSB4151
        .uleb128 .LFE4151-.LFSB4151
        .uleb128 0x3
        .byte   0x53
        .byte   0x93
        .uleb128 0x8
        .byte   0

[Bug debug/103241] Odd 0 length entries in location lists

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
     '-dA'
          Annotate the assembler output with miscellaneous debugging
          information.
It prints comments into the assembly, making the debug info in there readable
for humans.

[Bug debug/103241] Odd 0 length entries in location lists

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103241

--- Comment #14 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Hi, Will, Jakub, Martin,

There's nothing particularly unusual about apparently empty ranges, especially
when views are enabled, since the very point of location views is to enable
multiple states to be distinguished at the same PC.

It is a little odd that an additional location entry gets emitted for prot at
function entry.  I suppose inspection of gimple dumps will show some SSA
assignment apparently setting some prot version, and that we end up outputting
a new entry for it.  The difference between the two locations, one without and
the other with DW_OP_piece, suggests that some internal state change was
perceived between one view and the other; it might be something about
(do-nothing) promotions between the argument bindings for the prototype and the
body.

We might be able to get rid of the restatement of the binding with some more
effort.