similar to: [LLVMdev] C++ type erasure in llvm-g++

On Mar 24, 2009, at 8:40 AM, Luke Dalessandro wrote: > Can someone more familiar with the llvm-gcc infrastructure comment on > the difficulty of generating more strongly typed virtual function > tables > rather than just having them all be variable length arrays of pointers > of unknown type and casting to the "known" type before the call? The easiest way would be to

Mike Stump wrote: > On Mar 24, 2009, at 8:40 AM, Luke Dalessandro wrote: >> Can someone more familiar with the llvm-gcc infrastructure comment on >> the difficulty of generating more strongly typed virtual function >> tables >> rather than just having them all be variable length arrays of pointers >> of unknown type and casting to the "known" type

On Mar 24, 2009, at 10:22 AM, Luke Dalessandro wrote: > OK, so it's mainly a problem of becoming comfortable with the llvm-gcc > internals that are affected and not a fundamental whole-compiler > design > problem. That's correct. > So I can essentially rematerialize the vtable types by pushing things > back through from the indirect calls in the program. Wouldn't

Mike Stump wrote: > On Mar 24, 2009, at 10:22 AM, Luke Dalessandro wrote: > >> I guess that alias analysis doesn't always "trust" casts, where if I >> manually >> pushed back I would be assuming that the casts are correct? > > Once all the pushing is in, one should be able to discover that the > casts all convert to the same type, and remove

[Was initially posted on cfe-users, sorry.] Hi, I'm sorry my message is quite long, the TL;DR version is "g++ and clang++ seem to have different opinions on how RTTI, templates, and ELF visibility should interact". I can't tell whether this is a bug or not: I have found no relevant documentation that could help me decide whether this behavior is meant, or not. All I can say

Hi all, I was wondering whether there's any existing code to find all possible targets of a function pointer in LLVM, and, if not, if there were a smarter way to go about writing something to accomplish this than the obvious way of recursively following the def-use chains and creating an aggregate set. --Patrick

Patrick Alexander Simmons wrote: > Hi all, > > I was wondering whether there's any existing code to find all possible > targets of a function pointer in LLVM, and, if not, if there were a > smarter way to go about writing something to accomplish this than the > obvious way of recursively following the def-use chains and creating an > aggregate set. I think the only

On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > As you may know modern C++ debuggers (GDB and LLDB) support dynamic type > identification for polymorphic objects, by utilizing C++ RTTI. > Unfortunately this feature does not work with Clang and GDB >= 7.x . The > last compiler that worked well was G++ 6.x >

Hi all, As you may know modern C++ debuggers (GDB and LLDB) support dynamic type identification for polymorphic objects, by utilizing C++ RTTI. Unfortunately this feature does not work with Clang and GDB >= 7.x . The last compiler that worked well was G++ 6.x I've asked about this issue both on GDB and LLDB maillists. Unfortunately it's hard or impossible to fix it on debugger side.

To explain to others who didn't follow that thread: GDB currently does something amazingly stupid (and has since i wrote it) to find the RTTI type. There were no other good options at the type. What it does is find the vtable for the object, find the symbol that represents the vtable, demangle it, , chops off "vtable for", and tries to find the symbol for the string that results.

Hi all, I'm currently working on a C-like scripting language compiler backend designed to emit LLVM code. This code will be loaded into LLVM's JIT at runtime and will make calls into a C++ library (including calling virtual methods on C++ objects). The translation from our AST to an llvm::Module is fairly straightforward, the difficulty, however, comes in generating the appropriate

On Sat, Mar 3, 2018 at 8:20 PM Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> As you may know modern C++ debuggers (GDB and LLDB) support dynamic type >> identification for polymorphic objects, by utilizing C++ RTTI.

On Mon, Mar 5, 2018 at 8:37 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Sat, Mar 3, 2018 at 8:20 PM Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi all, >>> >>> As you may know

On Mon, Mar 5, 2018 at 9:09 AM Daniel Berlin <dberlin at dberlin.org> wrote: > On Mon, Mar 5, 2018 at 8:37 AM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Sat, Mar 3, 2018 at 8:20 PM Daniel Berlin via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev <

On Mon, Mar 5, 2018, 9:26 AM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Mar 5, 2018 at 9:09 AM Daniel Berlin <dberlin at dberlin.org> wrote: > >> On Mon, Mar 5, 2018 at 8:37 AM, David Blaikie <dblaikie at gmail.com> wrote: >> >>> >>> >>> On Sat, Mar 3, 2018 at 8:20 PM Daniel Berlin via llvm-dev < >>> llvm-dev

> On Mar 3, 2018, at 11:30 PM, Daniel Berlin via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > To explain to others who didn't follow that thread: > > GDB currently does something amazingly stupid (and has since i wrote it) to find the RTTI type. There were no other good options at the type. > > What it does is find the vtable for the object, find the symbol

On Mon, Mar 5, 2018 at 11:55 PM, Roman Popov <ripopov at gmail.com> wrote: > I don't understand how extra vtable ref DIE will help in case on > non-polymorphic classes. If you remove virtual destructor from example, > vtable won't be generated for class, but DWARF will still have incorrect > ambiguous names for types. > 1. Calling them incorrect is ... not right. As

I don't understand how extra vtable ref DIE will help in case on non-polymorphic classes. If you remove virtual destructor from example, vtable won't be generated for class, but DWARF will still have incorrect ambiguous names for types. It will become a problem when you need to use debuginfo as a C++ runtime reflection (I've already seen this in a couple of projects). Or when you need

Dear Mailing List, This might sound unconventional, but I am trying to access a C++ objects vtable to pass as an argument to a function call for a library function I created. Creating & inserting a function call at the correct location in LLVM is done. I have learned that C++ objects are represented as struct types. But I'm just not quite sure how to get at the vtable pointer within,

On Tue, Mar 6, 2018 at 9:49 AM Daniel Berlin <dberlin at dberlin.org> wrote: > On Tue, Mar 6, 2018 at 9:20 AM, Roman Popov <ripopov at gmail.com> wrote: > >> I wonder if abi::__cxa_demangle guarantees unambigous names? >>>> >>> >>> No, it does not. >>> >> >> Interesting. Can you give an example of type where it fails?