New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: invalid dwarf frames #8846

Open
ribrdb opened this Issue Sep 30, 2014 · 7 comments

Comments

Projects
None yet
6 participants
@ribrdb
Contributor

ribrdb commented Sep 30, 2014

What does 'go version' print?
go version go1.3 darwin/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. Compile test.go http://play.golang.org/p/8G9JQFMlmY
2. Run lldb test
3. b main.foo
4. run

What happened?
lldb segfaulted

What should have happened instead?
no segfault

Please provide any additional information below.
It looks to me like the go compiler is generating invalid dwarf frames. I can't really
follow the code in dwarf.c to tell what's going on. Here's what dwarfdump shows:

0x00000014: FDE
        length: 0x00000020
   CIE_pointer: 0x00000000
    start_addr: 0x0000000000002000 main.foo
    range_size: 0x0000000000000060 (end_addr = 0x0000000000002060)
  Instructions: 0x0000000000002000: CFA=rsp+8     rip=[rsp]
                DW_CFA_advance_loc (25)
                DW_CFA_def_cfa_offset_sf (rax, 8)
                0x0000000000002019: CFA=rsp+8     rip=[rsp]
                DW_CFA_advance_loc (55)
                DW_CFA_def_cfa_offset_sf (rax, 24)
                0x0000000000002050: CFA=rsp+24    rip=[rsp+16]
                DW_CFA_advance_loc (16)
                DW_CFA_def_cfa_offset_sf (rax, 8)
                DW_CFA_nop
                DW_CFA_nop
                DW_CFA_nop
                0x0000000000002060: CFA=rsp+8     rip=[rsp]

If I'm reading the dissasembly right, I think the rows should be

0x0000000000002000: CFA=rsp+8     rip=[rsp]
0x0000000000002019: CFA=rsp+24     rip=[rsp+16]
0x0000000000002050: CFA=rsp+8    rip=[rsp]

Also, dwarfdump --verify complains because the row for 0x2060 is beyond the address
range of the function.

Here's the disassembled function:
test`main.foo at test.go:3:
test[0x2000]:  movq   %gs:0x8a0, %rcx
test[0x2009]:  cmpq   (%rcx), %rsp
test[0x200c]:  ja     0x2015                    ; main.foo + 21 at test.go:3
test[0x200e]:  callq  0x21710                   ; runtime.morestack8_noctxt at
asm_amd64.s:495
test[0x2013]:  jmp    0x2000                    ; main.foo at test.go:3
test[0x2015]:  subq   $0x10, %rsp
test[0x2019]:  leaq   0x2b800, %rbx
test[0x2021]:  leaq   (%rsp), %rbp
test[0x2025]:  movq   %rbp, %rdi
test[0x2028]:  movq   %rbx, %rsi
test[0x202b]:  movsq  (%rsi), %es:(%rdi)
test[0x202d]:  movsq  (%rsi), %es:(%rdi)
test[0x202f]:  callq  0x10770                   ; runtime.printstring at print.c:373
test[0x2034]:  callq  0x107e0                   ; runtime.printsp at print.c:384
test[0x2039]:  movq   0x18(%rsp), %rbx
test[0x203e]:  movq   %rbx, (%rsp)
test[0x2042]:  callq  0x10620                   ; runtime.printint at print.c:340
test[0x2047]:  callq  0x10820                   ; runtime.printnl at print.c:390
test[0x204c]:  addq   $0x10, %rsp
test[0x2050]:  retq
test[0x2051]:  addb   %al, (%rax)
test[0x2053]:  addb   %al, (%rax)
test[0x2055]:  addb   %al, (%rax)
test[0x2057]:  addb   %al, (%rax)
test[0x2059]:  addb   %al, (%rax)
test[0x205b]:  addb   %al, (%rax)
test[0x205d]:  addb   %al, (%rax)
@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Sep 30, 2014

Comment 1:

I believe this problem is fixed by https://golang.org/cl/112750043 .  Can you
check with tip, or with 1.3 with that patch included?

Labels changed: added repo-main, release-none.

@ribrdb

This comment has been minimized.

Contributor

ribrdb commented Oct 1, 2014

Comment 2:

Oops, I tested it at tip and still got a debugger crash so I just assumed it was the
same thing, but the frames do look correct there. I'll have to debug that crash more.
However dwarfdump --verify still complains because rows are supposed to have addresses
< the FDE's end address but one gets output for the end address itself.
@bpowers

This comment has been minimized.

Contributor

bpowers commented Oct 1, 2014

Comment 3:

I just tried this on tip.  I was not able to put a breakpoint on main.foo - I believe
because main.foo is inlined.  If I built with `go build -gcflags='-l'` I could indeed
breakpoint main.foo, and cause lldb to segfault.
I'm running on Linux with lldb version 3.4.2.  FWIW the following is the lldb backtrace:
#0  __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136
#1  0x00007f396441851e in memcpy (__len=8, __src=0xc208031f80, __dest=0x1263290) at
/usr/include/bits/string3.h:51
#2  lldb_private::Value::GetValueAsData (this=this@entry=0x7fff2322ac20,
exe_ctx=exe_ctx@entry=0x7fff2322aad0, data=..., data_offset=data_offset@entry=0,
module=<optimized out>)
    at Value.cpp:582
#3  0x00007f3964432562 in lldb_private::ValueObjectVariable::UpdateValue
(this=0x11deda0) at ValueObjectVariable.cpp:241
#4  0x00007f396441d579 in lldb_private::ValueObject::UpdateValueIfNeeded
(this=0x11deda0, update_format=<optimized out>) at ValueObject.cpp:212
#5  0x00007f396441d6f3 in lldb_private::ValueObject::GetValueAsCString (this=0x11deda0)
at ValueObject.cpp:1477
#6  0x00007f39643d4478 in FormatPromptRecurse (format=<optimized out>,
sc=<optimized out>, exe_ctx=<optimized out>, addr=<optimized out>,
s=..., end=end@entry=0x7fff2322b170, 
    valobj=0x0) at Debugger.cpp:2285
#7  0x00007f39643d20c8 in FormatPromptRecurse (format=<optimized out>,
sc=<optimized out>, exe_ctx=<optimized out>, addr=<optimized out>,
s=..., end=end@entry=0x7fff2322b470, 
    valobj=<optimized out>) at Debugger.cpp:1526
#8  0x00007f39643d20c8 in FormatPromptRecurse (format=<optimized out>,
sc=sc@entry=0x7fff2322b7b0, exe_ctx=exe_ctx@entry=0x7fff2322b770, addr=addr@entry=0x0,
s=..., 
    end=end@entry=0x0, valobj=<optimized out>) at Debugger.cpp:1526
#9  0x00007f39643d5d53 in lldb_private::Debugger::FormatPrompt (format=<optimized
out>, sc=0x7fff2322b7b0, exe_ctx=exe_ctx@entry=0x7fff2322b770, addr=addr@entry=0x0,
s=..., 
    valobj=valobj@entry=0x0) at Debugger.cpp:2622
#10 0x00007f3964735fee in lldb_private::Thread::DumpUsingSettingsFormat
(this=this@entry=0x7f3940000910, strm=..., frame_idx=frame_idx@entry=0) at
Thread.cpp:1856
#11 0x00007f39647362c8 in lldb_private::Thread::GetStatus
(this=this@entry=0x7f3940000910, strm=..., start_frame=start_frame@entry=0,
num_frames=num_frames@entry=1, 
    num_frames_with_source=num_frames_with_source@entry=1) at Thread.cpp:1959
#12 0x00007f39646fa92a in lldb_private::Process::GetThreadStatus
(this=this@entry=0x11a74d0, strm=...,
only_threads_with_stop_reason=only_threads_with_stop_reason@entry=true, 
    start_frame=start_frame@entry=0, num_frames=num_frames@entry=1, num_frames_with_source=num_frames_with_source@entry=1) at Process.cpp:5596
#13 0x00007f39643674dd in CommandObjectProcessStatus::DoExecute (this=<optimized
out>, command=..., result=...) at CommandObjectProcess.cpp:1607
#14 0x00007f39644e5a8d in lldb_private::CommandObjectParsed::Execute (this=0x1110aa0,
args_string=<optimized out>, result=...) at CommandObject.cpp:1037
#15 0x00007f39644dfded in lldb_private::CommandInterpreter::HandleCommand
(this=0x10ff7f0, command_line=<optimized out>, command_line@entry=0x411fb8
"process status", 
    lazy_add_to_history=lazy_add_to_history@entry=lldb_private::eLazyBoolNo, result=..., override_context=override_context@entry=0x0, 
    repeat_on_empty_command=repeat_on_empty_command@entry=true, no_context_switching=false) at CommandInterpreter.cpp:1853
#16 0x00007f39642a85db in lldb::SBCommandInterpreter::HandleCommand
(this=0x7fff2322be30, command_line=0x411fb8 "process status", result=...,
add_to_history=<optimized out>)
    at SBCommandInterpreter.cpp:122
#17 0x000000000040a542 in Driver::HandleProcessEvent (this=0x7fff2322ed00, event=...) at
Driver.cpp:1104
#18 0x000000000040b8da in Driver::MainLoop (this=this@entry=0x7fff2322ed00) at
Driver.cpp:1635
#19 0x0000000000408f84 in main (argc=2, argv=0x7fff2322ef38, envp=<optimized out>)
at Driver.cpp:1802
@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Oct 1, 2014

Comment 4:

Does https://golang.org/cl/150370043 help with the issue of reporting line
number info for the final address of an FDE?
I have no idea what the lldb crash means.
@ribrdb

This comment has been minimized.

Contributor

ribrdb commented Oct 1, 2014

Comment 5:

Yes, dwarfdump --verify is happy with this patch.
The lldb crash is because it's calculating the wrong address for the argument to
main.foo.
But as far as I can tell the debug info is correct, so I'll file an lldb bug.
@gopherbot

This comment has been minimized.

gopherbot commented Oct 3, 2014

Comment 6:

CL https://golang.org/cl/150370043 mentions this issue.
@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Oct 8, 2014

Comment 7:

This issue was updated by revision 060b240.

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/150370043

@ribrdb ribrdb added new labels Oct 8, 2014

@bradfitz bradfitz removed the new label Dec 18, 2014

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

@rsc rsc changed the title from cmd/ld: invalid dwarf frames to cmd/link: invalid dwarf frames Jun 8, 2015

wheatman added a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018

cmd/ld: don't add line number info for the final address of an FDE
This makes dwardump --verify happy.

Update golang#8846

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/150370043

wheatman added a commit to wheatman/go-akaros that referenced this issue Jun 26, 2018

cmd/ld: don't add line number info for the final address of an FDE
This makes dwardump --verify happy.

Update golang#8846

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/150370043

wheatman added a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018

cmd/ld: don't add line number info for the final address of an FDE
This makes dwardump --verify happy.

Update golang#8846

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/150370043

wheatman added a commit to wheatman/go-akaros that referenced this issue Jul 30, 2018

cmd/ld: don't add line number info for the final address of an FDE
This makes dwardump --verify happy.

Update golang#8846

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/150370043
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment