[Lldb-commits] [PATCH] D33504: Fix FDE indexing while scan debug_info section

[Pavel Labath via lldb-commits]

+lldb-commits

Yes, that is certainly a viable approach. If there is a subset of
dwarf that we are capable of parsing correctly then it would be great
to enable that.

On 25 May 2017 at 16:46, Tatyana Krasnukha
<Tatyana.Krasnukha at synopsys.com> wrote:
> This binary uses DWARF 4, that introduces two additional fields in CIE - address_size and segment_size just after augmentation field. That’s why values are parsed  incorrectly.
> May be we should discard unwind plan if there is unsupported dwarf version for now?
>
> Thanks,
> Tatyana
>
> -----Original Message-----
> From: Pavel Labath [mailto:labath at google.com]
> Sent: Thursday, 25 May, 2017 5:45 PM
> To: Tatyana.Krasnukha at synopsys.com
> Subject: Re: [PATCH] D33504: Fix FDE indexing while scan debug_info section
>
> Hey, try the attached binary for size.
>
> It was generated from the source file in lldb/test/testcases/functionalities/breakpoint/breakpoint_conditions/main.c,
> while targetting android arm64.
>
> You should be able to create a test binary for yourself locally (assuming you're on linux) like this:
> $ cat a.c
> int a(char *x) { return *x; }
>
> int f() {
>   return a(0);
> }
>
> int g() {
>   return 1+f();
> }
>
> int _start() { return 2+g(); }
>
> $ clang -fno-exceptions -fno-unwind-tables -g a.c -nostdlib
>
> If you debug the binary with and stop in the ParseCIE function, you will see that it parses the entry incorrectly:
> Process 39688 stopped
> * thread #1, name = 'lldb', stop reason = step over
>     frame #0: 0x00007ffff074bb53
> liblldb.so.5`lldb_private::DWARFCallFrameInfo::ParseCIE(this=0x0000000000613280,
> cie_offset=0) at DWARFCallFrameInfo.cpp:303
>    300    cie_sp->data_align = (int32_t)m_cfi_data.GetSLEB128(&offset);
>    301    cie_sp->return_addr_reg_num = m_cfi_data.GetU8(&offset);
>    302
> -> 303    if (cie_sp->augmentation[0]) {
>    304      // Get the length of the eh_frame augmentation data
>    305      // which starts with a ULEB128 length in bytes
>    306      const size_t aug_data_len = (size_t)m_cfi_data.GetULEB128(&offset);
>
> (lldb) fr var cie_sp._M_ptr[0]
> (lldb_private::DWARFCallFrameInfo::CIE) cie_sp._M_ptr[0] = {
>   cie_offset = 0
>   version = '\x04'
>   augmentation = ""
>   code_align = 8 <====== wrong
>   data_align = 0 <====== wrong
>   return_addr_reg_num = 1 <===== wrong
>   inst_offset = 0
>   inst_length = 0
>   ptr_encoding = '\0'
>   lsda_addr_encoding = '\xff'
>   personality_loc = 18446744073709551615
>   initial_row = {
>     m_offset = 0
>     m_cfa_value = {
>       m_type = unspecified
>       m_value = {
>         reg = (reg_num = 0, offset = 0)
>         expr = (opcodes = 0x0000000000000000, length = 0)
>       }
>     }
>     m_register_locations = size=0 {}
>   }
> }
>
> Correct parsing can be seen by running
> $ llvm-dwarfdump a.out
> .....
> .debug_frame contents:
>
> 00000000 00000014 ffffffff CIE
>   Version:               4
>   Augmentation:          ""
>   Address size:          8  <=== this shows up in code_align
>   Segment desc size:     0 <=== this shows up in data_align
>   Code alignment factor: 1 <=== this shows up in return_addr_reg_num
>   Data alignment factor: -8
>   Return address column: 16
>
>   DW_CFA_def_cfa: reg7 +8
>   DW_CFA_offset: reg16 -8
>   DW_CFA_nop:
>   DW_CFA_nop:
>   DW_CFA_nop:
>   DW_CFA_nop:
>
> 00000018 0000001c 00000000 FDE cie=00000000 pc=004000b0...004000c1
>   DW_CFA_advance_loc: 1
>   DW_CFA_def_cfa_offset: +16
>   DW_CFA_offset: reg6 -16
>   DW_CFA_advance_loc: 3
>   DW_CFA_def_cfa_register: reg6
> ....
>
>
> Interestingly, in the x86_64 linux case, lldb still manages to unwind correctly despite the bad parsing.
>
>
>
>
> On 25 May 2017 at 14:40, Tatyana Krasnukha via Phabricator <reviews at reviews.llvm.org> wrote:
>> tatyana-krasnukha added a comment.
>>
>> Yes, give those binaries, please.
>>
>>
>> Repository:
>>   rL LLVM
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_
>> D33504&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=8NZfjV_ZLY_S7gZyQMq8mj7tiN4
>> vlymPiSt0Wl0jegw&m=Ze6ANiK7goV6lSPJcY8QglIJ_tZC0gXeUuqpQ8n4K40&s=1vfSh
>> WELC8pd8-DQmAeW3QJDQgdMAJvn905_U-jVphM&e=
>>
>>
>>