search for: apple_objc

...tages 1-3 (i.e. producer/consumer in llvm and integration with lldb) of my original plan are now complete with one caveat. The caveat is that the .debug_names section is presently not a full drop-in replacement for the .apple_*** sections. The reason for that is that there is no equivalent to the .apple_objc section (which links an objc class/category name to all of its methods). I did not implement that, because I do not see a way to embed that kind of information to this section without some sort of an extension. Given that this was not required for my use case, I felt it would be best to leave this...

...h lldb) >> of my original plan are now complete with one caveat. > > Awesome! > >> The caveat is that the .debug_names section is presently not a full >> drop-in replacement for the .apple_*** sections. The reason for that >> is that there is no equivalent to the .apple_objc section (which links >> an objc class/category name to all of its methods). I did not >> implement that, because I do not see a way to embed that kind of >> information to this section without some sort of an extension. Given >> that this was not required for my use case, I...

> On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thank you all. I am going to try to reply to all comments in a single email. > > Regarding the .apple_objc idea, I am afraid the situation is not as > simple as just flipping a switch. Jonas is currently working on adding the support for DWARF5-style Objective-C accelerator tables to LLVM/LLDB/dsymutil. Based on the assumption that DWARF 4 and earlier are unaffected by any of this, I don't think...

On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote: > so I'm writing this email to see if there's anyone > else interested in this topic, and to try to synchronize our efforts. I am sure interested in DWARF-5 .debug_names. I wrote its producer+consumer for GDB (but not producing/using DW_IDX_DIE_offset as GDB cannot use it). > 1. add .debug_names support to

..., 2018, at 9:36 AM, Adrian Prantl <aprantl at apple.com> wrote: > > > > On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thank you all. I am going to try to reply to all comments in a single email. > > Regarding the .apple_objc idea, I am afraid the situation is not as > simple as just flipping a switch. > > > Jonas is currently working on adding the support for DWARF5-style Objective-C accelerator tables to LLVM/LLDB/dsymutil. Based on the assumption that DWARF 4 and earlier are unaffected by any of this, I d...

...t;> > >> > >> > >> > On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> > >> > Thank you all. I am going to try to reply to all comments in a single email. >> > >> > Regarding the .apple_objc idea, I am afraid the situation is not as >> > simple as just flipping a switch. >> > >> > >> > Jonas is currently working on adding the support for DWARF5-style Objective-C accelerator tables to LLVM/LLDB/dsymutil. Based on the assumption that DWARF 4 and earlie...

...t; On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > >> > > > >> > Thank you all. I am going to try to reply to all comments in a > single email. > > >> > > > >> > Regarding the .apple_objc idea, I am afraid the situation is not as > > >> > simple as just flipping a switch. > > >> > > > >> > > > >> > Jonas is currently working on adding the support for DWARF5-style > Objective-C accelerator tables to LLVM/LLDB/dsymutil. Ba...

...hat has generic definitions... Solution #3 will require compiler changes. So this is another vote to support the ability for a given class to be able to locate all of its functions, kind of like we need for Objective C where the class definition doesn't contain all of methods, so we have the .apple_objc section that provides this mapping for us. We would need something similar for C++. So maybe a possible solution is some sort of section that can specify all of the DIEs related to a class that are not contained in the class hierarchy itself. This would work for Objective C and for C++. Thoughts?...

...> Well, so does #2. Indeed. > >> So this is another vote to support the ability for a given class >> to be able to locate all of its functions, kind of like we need >> for Objective C where the class definition doesn't contain all of >> methods, so we have the .apple_objc section that provides this >> mapping for us. We would need something similar for C++. >> >> So maybe a possible solution is some sort of section that can >> specify all of the DIEs related to a class that are not contained >> in the class hierarchy itself. This would...

...t;> >>>> So this is another vote to support the ability for a given class >>>> to be able to locate all of its functions, kind of like we need >>>> for Objective C where the class definition doesn't contain all of >>>> methods, so we have the .apple_objc section that provides this >>>> mapping for us. We would need something similar for C++. >>>> >>>> So maybe a possible solution is some sort of section that can >>>> specify all of the DIEs related to a class that are not contained >>>> i...