Displaying 6 results from an estimated 6 matches for "dw_tag_structur".
Did you mean:
dw_tag_structure
2018 Jun 14
2
[lldb-dev] Adding DWARF5 accelerator table support to llvm
...ut, other options may be possible as well. What's not clear to me is
> whether these tables couldn't be replaced by extra information in the
> .debug_info section. It seems to me that these tables are trying to
> work around the issue that there is no straight way to go from a
> DW_TAG_structure type DIE describing an ObjC class to it's methods. If
> these methods (their forward declarations) were be present as children
> of the type DIE (as they are for c++ classes), then these tables may
> not be necessary. But maybe (probably) that has already been
> considered and deem...
2018 Jun 14
2
[lldb-dev] Adding DWARF5 accelerator table support to llvm
...well. What's not clear to me is
>> > whether these tables couldn't be replaced by extra information in the
>> > .debug_info section. It seems to me that these tables are trying to
>> > work around the issue that there is no straight way to go from a
>> > DW_TAG_structure type DIE describing an ObjC class to it's methods. If
>> > these methods (their forward declarations) were be present as children
>> > of the type DIE (as they are for c++ classes), then these tables may
>> > not be necessary. But maybe (probably) that has already be...
2018 Jun 14
3
[lldb-dev] Adding DWARF5 accelerator table support to llvm
...ut, other options may be possible as well. What's not clear to me is
> whether these tables couldn't be replaced by extra information in the
> .debug_info section. It seems to me that these tables are trying to
> work around the issue that there is no straight way to go from a
> DW_TAG_structure type DIE describing an ObjC class to it's methods. If
> these methods (their forward declarations) were be present as children
> of the type DIE (as they are for c++ classes), then these tables may
> not be necessary. But maybe (probably) that has already been
> considered and deem...
2018 Jun 14
2
[lldb-dev] Adding DWARF5 accelerator table support to llvm
...; >> > whether these tables couldn't be replaced by extra information in
> the
> > >> > .debug_info section. It seems to me that these tables are trying to
> > >> > work around the issue that there is no straight way to go from a
> > >> > DW_TAG_structure type DIE describing an ObjC class to it's methods.
> If
> > >> > these methods (their forward declarations) were be present as
> children
> > >> > of the type DIE (as they are for c++ classes), then these tables may
> > >> > not be necessary....
2018 Jun 13
2
[lldb-dev] Adding DWARF5 accelerator table support to llvm
> On Jun 13, 2018, at 11:18 AM, Jonas Devlieghere via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>
> Hi Pavel,
>
>> On Jun 13, 2018, at 6:56 AM, Pavel Labath <labath at google.com <mailto:labath at google.com>> wrote:
>>
>> Hello again,
>>
>> It's been nearly six months since my first email, so it's a good time
>> to
2018 Jun 15
2
[lldb-dev] Adding DWARF5 accelerator table support to llvm
...;> whether these tables couldn't be replaced by extra information in the
>>>>>>> .debug_info section. It seems to me that these tables are trying to
>>>>>>> work around the issue that there is no straight way to go from a
>>>>>>> DW_TAG_structure type DIE describing an ObjC class to it's methods. If
>>>>>>> these methods (their forward declarations) were be present as children
>>>>>>> of the type DIE (as they are for c++ classes), then these tables may
>>>>>>> not be necess...