Comments (13)
Sure enough, thanks for reporting this.
@epipho would you have any interest in looking into this? You've taken an interest in the variable evaluation side of things and had some great commits. If not, I'll start digging into it.
The following snippet will reproduce this:
func main() {
foo := `
i
am a
multiline
string
`
fmt.Println(foo)
}
Setting a breakpoint right at foo :=
and trying to print foo
will crash.
from delve.
I have run into this before.
The bad news is I am not sure what we can do about it as I don't think there is any information in the binary.
Instead of a location expression for the variable location I would expect a location list (http://www.dwarfstd.org/doc/dwarf-2.0.0.pdf section 2.4.6) that would give a set of instruction ranges that the variable is valid for but the binary does not contain a .debug_loc section.
The same problem exists for code that shadows variables
func main() {
f := "foo"
{
f := "bar"
fmt.Println(f)
}
fmt.Println(f)
}
This actually generates two variables, and there does not appear to be any way to disambiguate them.
<2><40>: Abbrev Number: 4 (DW_TAG_variable)
<41> DW_AT_name : f
<47> DW_AT_location : 5 byte block: 9c 11 a8 7f 22 (DW_OP_call_frame_cfa; DW_OP_consts: -88; DW_OP_plus)
<4d> DW_AT_type : <0x2939f>
<2><55>: Abbrev Number: 4 (DW_TAG_variable)
<56> DW_AT_name : f
<5c> DW_AT_location : 5 byte block: 9c 11 b8 7f 22 (DW_OP_call_frame_cfa; DW_OP_consts: -72; DW_OP_plus)
<62> DW_AT_type : <0x2939f>
Thoughts?
from delve.
@epipho that's unfortunate. I don't see a clear fix other than patching the linker(s) to emit the .debug_loc
section, or at the very least submitting an issue to the Go project to include that information.
from delve.
This weekend I will dig through the go issue tracker to see if this has been brought up. I wonder what the complexity of the change would be to add .debug_log to the linker.
from delve.
@epipho not sure, but I know there's a lot going on with the compiler / linker rewrites. I'll likely post something on golang-dev about this and another Dwarf tag I'd like the linker to emit in the .debug_info section.
A cursory glance through the issue tracker didn't reveal any existing issues surrounding this, but if you dive deeper and find anything definitely let me know.
from delve.
Which additional tags are you hoping for? For our purposes it might be nice
to have DW_TAG_lexical_block set so we can play nicer with scoping / autos.
On Thu, Mar 12, 2015 at 2:51 PM, Derek Parker [email protected]
wrote:
@epipho https://github.com/epipho not sure, but I know there's a lot
going on with the compiler / linker rewrites. I'll likely post something on
golang-dev about this and another Dwarf tag I'd like the linker to emit in
the .debug_info section.A cursory glance through the issue tracker didn't reveal any existing
issues surrounding this, but if you dive deeper and find anything
definitely let me know.—
Reply to this email directly or view it on GitHub
https://github.com/derekparker/delve/issues/83#issuecomment-78565836.
from delve.
I don't know if this is related, but after continued testing I get erratic behavior similar to what I reported above, but also on completely valid source lines. For example, breaking in the following function at fmt.Println(a1,a2)
and inspecting locals will list only uninitialized a1
, i.e. a1
with seemingly random size, len, and content.
func foo() {
var (
a1 = []int{1}
a2 = 2
)
//println("")
fmt.Println(a1, a2)
}
However, by uncommenting the println("")
statement, locals will list expected values for both a1
and a2
.
from delve.
Btw, I get identical behavior in the above example on both darwin and linux (vbox image).
from delve.
@epipho DW_OP_form_tls_address would be nice for getting at the G(oroutine) in thread local storage, since m->procid
can be unreliable and it can be difficult to map a scheduler M to a real OS thread.
@ivarg that's interesting... I'll try and play around with that example and check out the asm / debug info it generates, may be clues there. Not sure why a1 would be uninitialized in that example without that erroneous println call.
from delve.
Turns out I forgot to build with optimizations disabled. Building with -gcflags "-N"
makes this second behavior go away. Sorry for that. Original issue is still valid though.
from delve.
@ivarg no worries, that makes sense. I'll still look into it a bit to see how feasible it would be for Delve to handle programs built without -N.
FWIW dlv run
builds with -gcflags="-N -l"
. Are you building manually and pointing Delve to the binary?
from delve.
Yes, when testing I just go install
both dlv
and my test programs.
from delve.
As far as I can tell this is not unsafe anymore.
from delve.
Related Issues (20)
- panic when delve process is stopped HOT 1
- support for Termux debugger with the Android
- How build arm version HOT 1
- Support `dlv types` from DAP (the same way `types` is supported in the command line `dlv` REPL)
- polish go1.23 range-over-func UX HOT 1
- Does delve ignore // line instructions during debug HOT 1
- Breakpoints do not work in packages with a TestMain(*testing.M) function HOT 1
- Unable to print a package string const value during a breakpoint HOT 1
- Error clearing stack watchpoint HOT 2
- Add defer functions to follow-calls tracing option
- Breakpoint line numbers not matching HOT 1
- Hitting compile error when launching delve in devbox HOT 4
- `undefined behavior - version of Delve is too old for Go version 1.22.3 (maximum supported version 1.20)` HOT 2
- trace: allow tracing from (or skip tracing on) G-less threads
- panic when data length is greater than memCache size
- Unable to find escape variables when using Delve HOT 7
- Fail to set watchpoint after clearing one of four HOT 3
- Dwarf parsing infinite loop causes OOM HOT 1
- Feature request: restart the current function HOT 6
- Seeing a warning that delve is too old for the latest Go version 1.22.5 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from delve.