Displaying 3 results from an estimated 3 matches for "_ztv3lrt20rgbaucharframebuffer".
2013 Jan 01
0
[LLVMdev] IR function pointers
...an
offset in the vtable, stored in %1604. Very roughly for Unixy ABIs (and
loosely typed):
%vtable = load i8** %1604
%fptr = getelementptr %vtable, NNN
%1608 = load %fptr
Work out where that NNN offset actually is and then look at
RGBAucharFrameBuffer's vtable *definition* (the global symbol
@_ZTV3LRT20RGBAucharFrameBuffer, I believe: the _ZTV is the important bit)
and see which function is put in that offset. Unfortunately, it's all
rather complicated and the vtable may not even be defined in the file
you're compiling.
Why are these calls bothering you? It's possible there are better options
for your us...
2013 Jan 01
2
[LLVMdev] IR function pointers
I am coming up against a lot of function pointers in the IR, although
the corresponding source code does not have indirect calls.
For example: call void %1608(%"struct.LRT::RGBAucharFrameBuffer"* %1604)
How can I resolve the targets of these? Also, why are they appearing as
indirect calls in the IR, when they are direct calls in the source?
Thanks.
-Apala
2013 Jan 01
2
[LLVMdev] IR function pointers
...roughly for Unixy
> ABIs (and loosely typed):
>
> %vtable = load i8** %1604
> %fptr = getelementptr %vtable, NNN
> %1608 = load %fptr
>
> Work out where that NNN offset actually is and then look at
> RGBAucharFrameBuffer's vtable *definition* (the global symbol
> @_ZTV3LRT20RGBAucharFrameBuffer, I believe: the _ZTV is the important
> bit) and see which function is put in that offset. Unfortunately, it's
> all rather complicated and the vtable may not even be defined in the
> file you're compiling.
>
> Why are these calls bothering you? It's possible there are...