[Lldb-commits] [PATCH] D33504: Fix FDE indexing while scan debug_info section
Abid, Hafiz via lldb-commits
lldb-commits at lists.llvm.org
Fri May 26 09:51:05 PDT 2017
Please note that version in the debug_frame is is specific to the call frame information.
It is not the same as DWARF version number.
Regards,
Abid
________________________________________
From: lldb-commits <lldb-commits-bounces at lists.llvm.org> on behalf of Tatyana Krasnukha via lldb-commits <lldb-commits at lists.llvm.org>
Sent: Friday, May 26, 2017 12:47 PM
To: Pavel Labath; lldb-commits at lists.llvm.org
Subject: Re: [Lldb-commits] [PATCH] D33504: Fix FDE indexing while scan debug_info section
.debug_frame may exist, even if there is no other debugging information. In this case we cannot obtain DWARF version from debug_info and ParseCIE is the only place where we can get CIE version and check whether it is supported or not.
Thanks,
Tatyana
-----Original Message-----
From: Pavel Labath [mailto:labath at google.com]
Sent: Friday, 26 May, 2017 2:17 PM
To: Robinson, Paul <paul.robinson at sony.com>
Cc: Tatyana Krasnukha <Tatyana.Krasnukha at synopsys.com>; lldb-commits at lists.llvm.org
Subject: Re: [Lldb-commits] [PATCH] D33504: Fix FDE indexing while scan debug_info section
Yes, that would definitely be a good idea. I was just saying that we shouldn't gate *any* .debug_frame support on being able to read a
dwarf4 .debug_frame section.
BTW, we've had a short chat about this with Abidh on IRC, I am going to paste the relevant part here, to make sure everyone is on the same
page:
<labath> after looking at the code, i think the eh_frame/debug_frame choice should be per function, not per-module <labath> that's way more useful, and it should allow more reasonable testing <abidh> I am a little confused. You are saying that compiler should provide this per function choice <labath> no <labath> right <labath> so what the current patch does is:
<labath> if (we_have_eh_frame()) frame = eh_frame() else frame = debug_frame() <labath> (this is in the initialization code) <labath> and then later, when we actually try to get an unwind plan for some function, we do:
<labath> if (frame->can_you_unwind(function)) return
frame->get_unwind_plan(function)
<labath> what I am proposing instead is for the init code to do:
<labath> frame1 = eh_frame(); frame2 = debug_frame(); <labath> and then later on (this would be the UnwindTable::GetFuncUnwindersContainingAddress function) <labath> if (frame1->can_you_unwind(function)) return
frame1->get_unwind_plan(function)
<labath> else if (frame2->can_you_unwind(function)) return
frame2->get_unwind_plan(function)
<labath> so the choice which unwind section you use happens on a per-function basis
On 25 May 2017 at 22:42, Robinson, Paul <paul.robinson at sony.com> wrote:
> IANA lldb developer, but I should think lldb would want to understand
> a DWARF 4 .debug_frame section. (And it didn't change in DWARF 5,
> either!) --paulr
>
>> -----Original Message-----
>> From: lldb-commits [mailto:lldb-commits-bounces at lists.llvm.org] On
>> Behalf Of Pavel Labath via lldb-commits
>> Sent: Thursday, May 25, 2017 9:17 AM
>> To: Tatyana Krasnukha
>> Cc: lldb-commits at lists.llvm.org
>> Subject: Re: [Lldb-commits] [PATCH] D33504: Fix FDE indexing while
>> scan debug_info section
>>
>> +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=0x000000
>> 00006
>> 13280,
>> > 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_S7gZyQMq8mj7
>> >> tiN4
>> >> vlymPiSt0Wl0jegw&m=Ze6ANiK7goV6lSPJcY8QglIJ_tZC0gXeUuqpQ8n4K40&s=1
>> >> vfSh WELC8pd8-DQmAeW3QJDQgdMAJvn905_U-jVphM&e=
>> >>
>> >>
>> >>
>> _______________________________________________
>> lldb-commits mailing list
>> lldb-commits at lists.llvm.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cg
>> i-2Dbin_mailman_listinfo_lldb-2Dcommits&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWq
>> B0tg&r=yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0&m=RXVxPTeUUhRCtE9Y
>> _xnBGwFroOyq75MOvDBTDl7ClwI&s=v5444B71MWBm_FJgdo5qNsbjR2rIue6nQWOWAKL
>> 3CSQ&e=
_______________________________________________
lldb-commits mailing list
lldb-commits at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
More information about the lldb-commits
mailing list