golang/go#60493

Before this patch, the visibility of function arguments for purposes
like the `locals` command was considered to start on the line on which
they are declared. I believe this was incorrect; instead their
visibility should start at the beginning of the function. This makes a
difference for function declarations like:

1: func foo(
2:   a int,
3:   b int,
4: )

Here, foo() starts on line 1 (e.g. a breakpoint on "foo" will break on
:1), but "a" has a decl_line of :2 and "b" has :3. This was causing a
and b to not be readable for a few instructions at the beginning of the
function, although they should have been.

This patch fixes it by ignoring decl_line for function arguments,
essentially making them visible throughout the function.

Note that function arguments are not subject to the bug in location
lists described in golang/go#60493. That
issues describes how the loclists for some variables erroneously extends
to the end of the function's code, covering epilogue code related to
stack growth that should not be covered because the respective variables
have yet to be initialized when that code runs. The decl_line check
helps Delve avoid making the variables visible during that epilogue, and
thus prevents reading garbage. However, function arguments are
initialized when the stack growth runs, and they can be read just fine
during the epilogue (so their loclist is fine) - so this patch does not
introduce a regression (additionally, function args declared on the same
line as the function were already unprotected by the decl_line check).

Before this patch, the visibility of function arguments for purposes
like the `locals` command was considered to start on the line on which
they are declared. I believe this was incorrect; instead their
visibility should start at the beginning of the function. This makes a
difference for function declarations like:

1: func foo(
2:   a int,
3:   b int,
4: )

Here, foo() starts on line 1 (e.g. a breakpoint on "foo" will break on
:1), but "a" has a decl_line of :2 and "b" has :3. This was causing a
and b to not be readable for a few instructions at the beginning of the
function, although they should have been.

This patch fixes it by ignoring decl_line for function arguments,
essentially making them visible throughout the function.

Note that function arguments are not subject to the bug in location
lists described in golang/go#60493. That
issues describes how the loclists for some variables erroneously extends
to the end of the function's code, covering trailing code related to
stack growth that should not be covered because the respective variables
have yet to be initialized when that code runs. The decl_line check
helps Delve avoid making the variables visible during that trailing
code, and thus prevents reading garbage. However, function arguments are
already initialized when the stack growth runs, and they can be read
just fine from the respective PCs (so their loclist is fine). So, this
patch does not introduce a regression (additionally, function args
declared on the same line as the function were already unprotected by
the decl_line check).

Before this patch, the visibility of function arguments for purposes
like the `locals` command was considered to start on the line on which
they are declared. I believe this was incorrect; instead their
visibility should start at the beginning of the function. This makes a
difference for function declarations like:

1: func foo(
2:   a int,
3:   b int,
4: )

Here, foo() starts on line 1 (e.g. a breakpoint on "foo" will break on
:1), but "a" has a decl_line of :2 and "b" has :3. This was causing a
and b to not be readable for a few instructions at the beginning of the
function, although they should have been.

This patch fixes it by ignoring decl_line for function arguments,
essentially making them visible throughout the function.

Note that function arguments are not subject to the bug in location
lists described in golang/go#60493. That
issues describes how the loclists for some variables erroneously extends
to the end of the function's code, covering trailing code related to
stack growth that should not be covered because the respective variables
have yet to be initialized when that code runs. The decl_line check
helps Delve avoid making the variables visible during that trailing
code, and thus prevents reading garbage. However, function arguments are
already initialized when the stack growth runs, and they can be read
just fine from the respective PCs (so their loclist is fine). So, this
patch does not introduce a regression (additionally, function args
declared on the same line as the function were already unprotected by
the decl_line check).

This patch fixes some incorrect DWARF location lists. Before this patch,
a location list for a variable that was available until the "end of its
function" erroneously extended over trailing code that dealt with the
stack growth code. The code in question is placed at the end of the
function, but it is morally part of the function's prologue (the
prologue jumps to it if stack growth is needed, and this trailer then
jumps back to the prologue). Thus, for the purposes of the location
lists, it should be treated more like the beginning of the function than
the end of the function; instructions for reading variables at the end
of the function do not apply in this code region.

The patch makes the loclists for regular variable not expand over this
trailing code, as they do not yet exist when this code runs. Function
arguments are special though - they do exist when the stack growth code
runs, and generally can be read. For function arguments, this patch
"fixes up" the location lists generated by the compiler after the linker
has inserted the stack growth code, as described below:

The layout of a function's code is as follows:

<function prologue jumps to the stack growth trailer>
<regular function code>
...
ret
movq    %rax, 0x38(%rsp)                  <- FuncLogicalEnd
movq    %rbx, 0x40(%rsp)
...
callq   <runtime.morestack_noctxt.abi0>   <- StackGrowthCall
movq    0x38(%rsp), %rax
movq    0x40(%rsp), %rbx
...
jmp     <beginning of function>
int3                                      <- FuncPhysicalEndA

The stack growth trailer consists of register spilling (starting at
FuncLogicalEnd), a call to the runtime stack growth function (marked by
StackGrowthCall), and then register unspilling (up until
FuncPhysicalEnd).
A variable that's available at the beginning of the function (i.e. a function
argument) is available in between [FuncLogicalEnd,StackGrowthCall) using the
same DWARF instructions as the ones used at the beginning of the function.
The variable is then available in between [StackGrowthCall,FuncPhysicalEnd)
with new instructions referencing the stack location where the variable was
spilled to.

The patch only performs this fixup for function arguments on amd64; the
tracking that linker needs to do for identifying FuncLoficalEnd and
StackGrowthCall is architecture-specific and I didn't go through the
trouble of doing it outside amd64.

Fixes golang#60493

This patch fixes some incorrect DWARF location lists. Before this patch,
a location list for a variable that was available until the "end of its
function" erroneously extended over trailing code that dealt with the
stack growth code. The code in question is placed at the end of the
function, but it is morally part of the function's prologue (the
prologue jumps to it if stack growth is needed, and this trailer then
jumps back to the prologue). Thus, for the purposes of the location
lists, it should be treated more like the beginning of the function than
the end of the function; instructions for reading variables at the end
of the function do not apply in this code region.

The patch makes the loclists for regular variable not expand over this
trailing code, as they do not yet exist when this code runs. Function
arguments are special though - they do exist when the stack growth code
runs, and generally can be read. For function arguments, this patch
"fixes up" the location lists generated by the compiler after the linker
has inserted the stack growth code, as described below:

The layout of a function's code is as follows:

<function prologue jumps to the stack growth trailer>
<regular function code>
...
ret
movq    %rax, 0x38(%rsp)                  <- FuncLogicalEnd
movq    %rbx, 0x40(%rsp)
...
callq   <runtime.morestack_noctxt.abi0>   <- StackGrowthCall
movq    0x38(%rsp), %rax
movq    0x40(%rsp), %rbx
...
jmp     <beginning of function>
int3                                      <- FuncPhysicalEndA

The stack growth trailer consists of register spilling (starting at
FuncLogicalEnd), a call to the runtime stack growth function (marked by
StackGrowthCall), and then register unspilling (up until
FuncPhysicalEnd).
A variable that's available at the beginning of the function (i.e. a function
argument) is available in between [FuncLogicalEnd,StackGrowthCall) using the
same DWARF instructions as the ones used at the beginning of the function.
The variable is then available in between [StackGrowthCall,FuncPhysicalEnd)
with new instructions referencing the stack location where the variable was
spilled to.

The patch only performs this fixup for function arguments on amd64; the
tracking that linker needs to do for identifying FuncLoficalEnd and
StackGrowthCall is architecture-specific and I didn't go through the
trouble of doing it outside amd64.

Fixes golang#60493

Change-Id: I8ccc9ae802bddc9427ecc4ffc5a26f172a8d6b83

Add a test with loose assertions about location lists, checking that
60493 was fixed. The bug is fixed by https://go.dev/cl/502117 on arm64
and amd64, the same architectures as the ones where these tests
run.

For golang/go#60493

Change-Id: I55a356cbe41004a956b5dfb863ed1a403551c1cb

This patch fixes some incorrect DWARF location lists. Before this patch,
a location list for a variable that was available until the "end of its
function" erroneously extended over trailing code that dealt with the
stack growth code. The code in question is placed at the end of the
function, but it is morally part of the function's prologue (the
prologue jumps to it if stack growth is needed, and this trailer then
jumps back to the prologue). Thus, for the purposes of the location
lists, it should be treated more like the beginning of the function than
the end of the function; instructions for reading variables at the end
of the function do not apply in this code region.

The patch makes the loclists for regular variable not expand over this
trailing code, as they do not yet exist when this code runs. Function
arguments are special though - they do exist when the stack growth code
runs, and generally can be read. For function arguments, this patch
"fixes up" the location lists generated by the compiler after the linker
has inserted the stack growth code, as described below:

The layout of a function's code is as follows:

<function prologue jumps to the stack growth trailer>
<regular function code>
...
ret
movq    %rax, 0x38(%rsp)                  <- FuncLogicalEnd
movq    %rbx, 0x40(%rsp)
...
callq   <runtime.morestack_noctxt.abi0>   <- StackGrowthCall
movq    0x38(%rsp), %rax
movq    0x40(%rsp), %rbx
...
jmp     <beginning of function>
int3                                      <- FuncPhysicalEndA

The stack growth trailer consists of register spilling (starting at
FuncLogicalEnd), a call to the runtime stack growth function (marked by
StackGrowthCall), and then register unspilling (up until
FuncPhysicalEnd).
A variable that's available at the beginning of the function (i.e. a function
argument) is available in between [FuncLogicalEnd,StackGrowthCall) using the
same DWARF instructions as the ones used at the beginning of the function.
The variable is then available in between [StackGrowthCall,FuncPhysicalEnd)
with new instructions referencing the stack location where the variable was
spilled to.

The patch only performs this fixup for function arguments on amd64 and
arm64; the tracking that linker needs to do for identifying
FuncLoficalEnd and StackGrowthCall is architecture-specific and I didn't
go through the trouble of doing it outside these two archs.

Fixes golang#60493

Change-Id: I8ccc9ae802bddc9427ecc4ffc5a26f172a8d6b83

The test harness for the variable location tests in "dwtest"
was using an out-of-date version of Delve; update to something
more recent.

Updates golang/go#60493.

Change-Id: I4e72fd12fa1c6e07094067402b2c8693e37eea39
Reviewed-on: https://go-review.googlesource.com/c/debug/+/504836
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>

Add a test with loose assertions about location lists, checking that
60493 was fixed. The bug is fixed by https://go.dev/cl/502117 on arm64
and amd64, the same architectures as the ones where these tests
run.

For golang/go#60493

Change-Id: I55a356cbe41004a956b5dfb863ed1a403551c1cb

Add a test with loose assertions about location lists, checking that
60493 was fixed. The bug is fixed by https://go.dev/cl/502117 on arm64
and amd64, the same architectures as the ones where these tests
run.

For golang/go#60493

Change-Id: I55a356cbe41004a956b5dfb863ed1a403551c1cb

Add a test with loose assertions about location lists, checking that
60493 was fixed. The bug is fixed by https://go.dev/cl/502117 on arm64
and amd64, the same architectures as the ones where these tests
run.

For golang/go#60493

Change-Id: I55a356cbe41004a956b5dfb863ed1a403551c1cb

Add a test with loose assertions about location lists, checking that
60493 was fixed. The bug is fixed by https://go.dev/cl/502117 on arm64
and amd64, the same architectures as the ones where these tests
run.

For golang/go#60493

Change-Id: I55a356cbe41004a956b5dfb863ed1a403551c1cb

This patch fixes some incorrect DWARF location lists. Before this patch,
a location list for a variable that was available until the "end of its
function" erroneously extended over trailing code that dealt with the
stack growth code. The code in question is placed at the end of the
function, but it is morally part of the function's prologue (the
prologue jumps to it if stack growth is needed, and this trailer then
jumps back to the prologue). Thus, for the purposes of the location
lists, it should be treated more like the beginning of the function than
the end of the function; instructions for reading variables at the end
of the function do not apply in this code region.

The patch makes the loclists for regular variable not expand over this
trailing code, as they do not yet exist when this code runs. Function
arguments are special though - they do exist when the stack growth code
runs, and generally can be read. For function arguments, this patch
"fixes up" the location lists generated by the compiler after the linker
has inserted the stack growth code, as described below:

The layout of a function's code is as follows:

<function prologue jumps to the stack growth trailer>
<regular function code>
...
ret
movq    %rax, 0x38(%rsp)                  <- FuncLogicalEnd
movq    %rbx, 0x40(%rsp)
...
callq   <runtime.morestack_noctxt.abi0>   <- StackGrowthCall
movq    0x38(%rsp), %rax
movq    0x40(%rsp), %rbx
...
jmp     <beginning of function>
int3                                      <- FuncPhysicalEndA

The stack growth trailer consists of register spilling (starting at
FuncLogicalEnd), a call to the runtime stack growth function (marked by
StackGrowthCall), and then register unspilling (up until
FuncPhysicalEnd).
A variable that's available at the beginning of the function (i.e. a function
argument) is available in between [FuncLogicalEnd,StackGrowthCall) using the
same DWARF instructions as the ones used at the beginning of the function.
The variable is then available in between [StackGrowthCall,FuncPhysicalEnd)
with new instructions referencing the stack location where the variable was
spilled to.

The patch only performs this fixup for function arguments on amd64 and
arm64; the tracking that linker needs to do for identifying
FuncLoficalEnd and StackGrowthCall is architecture-specific and I didn't
go through the trouble of doing it outside these two archs.

Fixes golang#60493

Change-Id: I8ccc9ae802bddc9427ecc4ffc5a26f172a8d6b83