Skip to content
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

Jump to bottom

cmd/link: invalid dwarf frames #8846

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

cmd/link: invalid dwarf frames #8846

ribrdb opened this issue Sep 30, 2014 · 7 comments
Milestone
Unplanned

Comments

@ribrdb
Copy link
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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link

Comment 6:

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

@ianlancetaylor
Copy link
Contributor

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 changed the title cmd/ld: invalid dwarf frames cmd/link: invalid dwarf frames Jun 8, 2015
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
@ianlancetaylor @wheatman
cmd/ld: don't add line number info for the final address of an FDE
0be602e 
This makes dwardump --verify happy.

Update golang#8846

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/150370043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 26, 2018
@ianlancetaylor @wheatman
cmd/ld: don't add line number info for the final address of an FDE
72b9ef1 
This makes dwardump --verify happy.

Update golang#8846

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/150370043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
@ianlancetaylor @wheatman
cmd/ld: don't add line number info for the final address of an FDE
3fcbabc 
This makes dwardump --verify happy.

Update golang#8846

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/150370043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 30, 2018
@ianlancetaylor @wheatman
cmd/ld: don't add line number info for the final address of an FDE
2b596dc 
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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
6 participants
@bradfitz @ribrdb @rsc @bpowers @ianlancetaylor @gopherbot