- 12 6月, 2018 1 次提交
-
-
由 aarzilli 提交于
-
- 09 6月, 2018 2 次提交
-
-
由 aarzilli 提交于
Maps were always loaded with using the default configuration during a reslice. This is probably a remnant from when we didn't let clients configure the load parameters.
-
由 aarzilli 提交于
If we don't build artifacts aren't removed after the tests run. Also add a check to prevent this mistake from reoccuring.
-
- 24 5月, 2018 4 次提交
-
-
由 Sergio Lopez 提交于
-
由 Sergio Lopez 提交于
If dwz binary is available in the system, test delve's ability to find deduplicated symbols in the DWARF information. dwzcompression.go contains a small C function (void fortytwo()) which calls glibc's fprintf with stdin as first argument. Normally, stdin will be present as a DW_TAG_variable as part of a DW_TAG_compile_unit named dwzcompression.cgo2.c. After running dwz on the binary, stdin is moved to a DW_TAG_partial_unit, which is imported from dwzcompression.cgo2.c with a DW_TAG_imported_unit. This test verifies that delve is able to find stdin symbol's type, as a way to confirm it understands dwz's compressed/deduplicated DWARF information.
-
由 Sergio Lopez 提交于
The EnableDWZCompression flag allows tests to request BuildFixture to run "dwz" on the Fixture's resulting binary to compress/deduplicate its DWARF sections.
-
由 Sergio Lopez 提交于
'dwz' is a tool that reduces the size of DWARF sections by deduplicating symbols. The deduplicated symbols are moved from their original 'compile unit' to a 'partial unit', which is then referenced from its original location with an 'imported unit' tag. In the case of Go binaries, all symbols are located in a single 'compile unit', and the name of each symbol contains a reference to its package, so 'dwz' is not able to deduplicate them. But still, some C symbols included in the binary are deduplicated, which also alters the structure of the DWARF sections, making delve unable to parse them (crashing in the attempt). While it would've been possible to simply ignore the C symbols, or blindly loading all then into BinaryInfo members (packageVars, Functions...), for correctness sake this change tries to do the right thing, staging symbols into temporary partialUnit objects, moving them to BinaryInfo when they are actually requested by a 'imported unit' tag.
-
- 23 5月, 2018 1 次提交
-
-
由 Chandrashekhara A 提交于
Add -t falg to "goroutines" command. For example, "goroutines -t" will print all the goroutines along with the stack trace.
-
- 22 5月, 2018 1 次提交
-
-
由 aarzilli 提交于
Passing --stdin-path /dev/tty will crash debugserver if /dev/tty can't be open. Fixes #1215
-
- 19 5月, 2018 1 次提交
-
-
由 aarzilli 提交于
Change the linux verison of proc/native and proc/gdbserial (with debugserver) so that they let the target process use the terminal when delve is launched in headless mode. Windows already worked, proc/gdbserial (with rr) already worked. I couldn't find a way to make proc/gdbserial (with lldb-server) work. No tests are added because I can't think of a way to test for foregroundness of a process. Fixes #65
-
- 16 5月, 2018 1 次提交
-
-
由 Jay Mundrawala 提交于
Go seems to be generating multiple compilation units that have the same file. I think this happens for functions that get inlined. Without this patch, those inlined functions break the ability to set a breakpoint at other lines in the file. I was able to load the same binary in gdb and set a breakpoints throughout the file without issue. ``` ➜ objdump --dwarf=decodedline automate-gateway | grep handler/users.go .../handler/users.go:[++] s/.../handler/users.go 20 0xb6dd88 .../handler/users.go:[++] s/.../handler/users.go 20 0xb6e50f .../handler/users.go:[++] s/automate-gateway/handler/users.go 32 0xb66640 ``` Inlined functions are still a little weird. setting a breakpoint on a function that gets inlined picks the first occurence. That being said, I think delve should still do something reasonable for the rest of the lines in the file.
-
- 10 5月, 2018 1 次提交
-
-
由 aarzilli 提交于
Fixes #1203
-
- 08 5月, 2018 1 次提交
-
-
由 aarzilli 提交于
So we don't have to worry about having a nil conf field, even if there is no configuration.
-
- 05 5月, 2018 1 次提交
-
-
由 Yuval Kohavi 提交于
-
- 27 4月, 2018 1 次提交
-
- 24 4月, 2018 3 次提交
-
-
由 aarzilli 提交于
Fixes #951
-
由 aarzilli 提交于
Caching the frame in variablesByTag is problematic: 1. accounting for variables that are (partially) stored in registers is complicated (see issue #1106) 2. for some types (strings, interfaces...) simply creating the Variable object reads memory, which therefore happens before we can do any caching. Instead cache the entire frame when the EvalScope object is created. The cached range is between the SP value of the current frame and the CFA of the preceeding frame, if available, or the CFA of the current frame otherwise. Fixes #1106
-
由 aarzilli 提交于
Change memCache so that the preloaded memory is not read immediately but only after the actual read to the preloaded range. This allows us to request caching the entire stack frame every time we create an eval scope and no unnecessary reads will be made even if the user is just trying to evaluate a global variable.
-
- 20 4月, 2018 2 次提交
-
-
由 Functionary Robot 提交于
Vet found the following errors: pkg/proc/moduledata.go:152: namedata[1] (8 bits) too small for shift of 8 pkg/proc/moduledata.go:170: taglendata[0] (8 bits) too small for shift of 8 The fix is to convert before shifting.
-
由 aarzilli 提交于
-
- 19 4月, 2018 1 次提交
-
-
由 aarzilli 提交于
Since we always forget to update the documentation lets check this automatically.
-
- 18 4月, 2018 1 次提交
-
-
由 Derek Parker 提交于
-
- 14 4月, 2018 4 次提交
-
-
由 aarzilli 提交于
Change evaluation of binary operators so that both && and || only evaluate their second argument conditionally, like go does.
-
由 aarzilli 提交于
I've seen TestFrameEvaluation fail in CI in the past. It's been a while since the last time and I couldn't reproduce it locally at all. I'd like to have some instrumentation in case it happens again.
-
由 aarzilli 提交于
printcontext should use SelectedGoroutine instead of trusting that the goroutine running on current thread matches the SelectedGoroutine. When the user switches to a parked goroutine CurrentThread and SelectedGoroutine will diverge. Almost all calls to printcontext are safe, they happen after a continue command returns when SelectedGoroutine and CurrentThread always agree, but the calls in frameCommand and listCommand are wrong. Additionally we should stop reporting an error when the debugger is stopped on an unknown PC address.
-
由 aarzilli 提交于
-
- 11 4月, 2018 4 次提交
-
-
由 aarzilli 提交于
-
由 aarzilli 提交于
-
由 aarzilli 提交于
The g command is bugged and causes that version of debugserver to crash. See: https://bugs.llvm.org/show_bug.cgi?id=36968 Fixes #1165
-
由 aarzilli 提交于
When gdbserial can not find debugserver or lldb-server the error message is always the same and it complains about lldb-server not being found. This is fine on linux (where the backend is unnecessary) but incomplete on macOS (where the backend is actually used). Make the error message clearer so that users who do not bother reading install instructions are not confused.
-
- 29 3月, 2018 1 次提交
-
-
由 Patrick 提交于
I found this issue (https://github.com/derekparker/delve/issues/514) where user alexbrainman gave a very helpful answer. Adding this to the official install-guide might help a lot of users.
-
- 28 3月, 2018 1 次提交
-
-
由 Martin Tournoij 提交于
-
- 27 3月, 2018 1 次提交
-
-
由 aarzilli 提交于
Go 1.10 added inlined calls to debug_info, this commit adds support for DW_TAG_inlined_call to delve, both for stack traces (where inlined calls will appear as normal stack frames) and to correct the behavior of next, step and stepout. The calls to Next and Frame of stackIterator continue to work unchanged and only return real stack frames, after reading each line appendInlinedCalls is called to unpacked all the inlined calls that involve the current PC. The fake stack frames produced by appendInlinedCalls are distinguished from real stack frames by having the Inlined attribute set to true. Also their Current and Call locations are treated differently. The Call location will be changed to represent the position inside the inlined call, while the Current location will always reference the real stack frame. This is done because: * next, step and stepout need to access the debug_info entry of the real function they are stepping through * we are already manipulating Call in different ways while Current is just what we read from the call stack The strategy remains mostly the same, we disassemble the function and we set a breakpoint on each instruction corresponding to a different file:line. The function in question will be the one corresponding to the first real (i.e. non-inlined) stack frame. * If the current function contains inlined calls, 'next' will not set any breakpoints on instructions that belong to inlined calls. We do not do this for 'step'. * If we are inside an inlined call that makes other inlined functions, 'next' will not set any breakpoints that belong to inlined calls that are children of the current inlined call. * If the current function is inlined the breakpoint on the return address won't be set, because inlined frames don't have a return address. * The code we use for stepout doesn't work at all if we are inside an inlined call, instead we call 'next' but instruct it to remove all PCs belonging to the current inlined call.
-
- 23 3月, 2018 2 次提交
-
-
由 Yasushi Saito 提交于
* Extend the "frame" command to set the current frame. Command frame 3 sets up so that subsequent "print", "set", "whatis" command will operate on frame 3. frame 3 print foo continues to work. Added "up", "down". They move the current frame up or down. Implementation note: This changes removes "scopePrefix" mode from the terminal/command.go and instead have the command examine the goroutine/frame value to see if it is invoked in a scoped context. * Rename Command.Frame -> Command.frame.
-
由 aarzilli 提交于
updates vendored version of x86asm, adds a symbol lookup function to pass to the disassembler. This will show global symbol names in the disassembly like go tool objdump does.
-
- 21 3月, 2018 2 次提交
-
-
由 aarzilli 提交于
Fixes #1151
-
由 aarzilli 提交于
Registers XMM1 and XMM2 get sometimes clobbered between the time we set them and the panic. There is no guarantee that they won't in the go spec so we shouldn't expect any register to keep its value. However since this seems to only affect 1 and 2 let's try to use 9 and 10 instead.
-
- 20 3月, 2018 1 次提交
-
-
由 Josh Soref 提交于
-
- 16 3月, 2018 1 次提交
-
-
由 Giuseppe 提交于
-
- 09 3月, 2018 1 次提交
-
-
由 aarzilli 提交于
Fixes #1145
-