llvm dev - Feb 2018 - [cfe-dev] Calling virtual elf functions under windows -> Adding ASM code

Still no progress with this problem. Only that non-member functions seems 
to be working...
Also:
Even when I set the target triple of the Module (when the file was parsed 
at runtime) to "COFF" nothing changes...


From:   Bjoern Gaier/HE/HORIBA
To:     llvm-dev at lists.llvm.org
Cc:     cfe-dev at lists.llvm.org
Date:   08.02.2018 12:28
Subject:        Re: Calling virtual elf functions under windows -> Adding 
ASM code


Hello everyone,

I'm sorry for "flooding" your inbox, but I wanted to extend my
message
which is shown below. The problem is still not solved and I'm more 
confused then before.
I compiled the code - the one seen in the pictures  to elf bc and to msvc 
(pecoff) bc. Then I used llc to generate assembler output.

In my opinion the involved functions are acting exactly the same. There 
are only some registers swapped. I should mention: when using the msvc bc 
code, then the calls via the interface are working.

I attach the assembly code of the involved code to. Could please anyone 
explain me the difference, which could cause the crash?

Kind regards
Björn




From:   Bjoern Gaier/HE/HORIBA
To:     llvm-dev at lists.llvm.org, cfe-dev at lists.llvm.org
Date:   07.02.2018 11:47
Subject:        Calling virtual elf functions under windows


Hello everyone reading this,

I'm totally confused and need an explanation. I'm also not sure if
it's a
clang or a LLVM subject. 

I'm working with Visual Studio 2015, LLVM 5.0.1 and Windows 7 64bit.

I have a simple project. With 2 Header files and 1 cpp file.
"Interface.h"
This file defines a simple class with two pure virtual member functions.

"SimpleResult.h"
This file defines a struct holding an integer

"CM_Elf.cpp"
This file defines a class (CM_Elf) implementing the interface from 
Interface.h
Also there is an instance of the class (named "elf").

I compile the CM_Elf.cpp to a CM_Elf.bc file via clang-cl but with target 
"x86_64-pc-windows-elf"


In another application I use LLVM to parse the BC file and use the 
ExecutionEngine to get some addresses.
What I want to archive is:
I want to call the implemented member functions of "elf".

1.) I execute all the global constructors collected by the ExecutionEngine
-> The constructor of elf gets called
2.) I use ExecutionEngine to get the address of "elf"
3.) I use the interface to execute Interface::init
-> Init gets called
4.) I use the interface to execute Interface::shutdown
-> CRASH!

When I swap the calls to init and shutdown, then everything works. So the 
virtual call to init seems to corrupt my stack - maybe it's the return 
value. Could it be a calling convention problem? But my target is still 
"windows" only msvc changed to elf...
When I compile CM_Elf for target "x86_64-pc-windows-msvc19.0.24215"
then
it works.

When I get the address of CM_Elf::init and CM_Elf::shutdown via the 
ExecutionEngine and call them without using the virtual table, then again 
everything works.

SO! Is it not possible to call virtual elf functions via there interface? 
But why does normal functions work? Also I reach the functions which are 
stored in the vTable of CM_Elf so the vTable is correct.

I append some pictures of the code... I hope someone could help me with 
this.

Kind regards
Björn





Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, 
USt.ID-Nr. DE 114 165 789
Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode, 
Heiko Lampert, Hiroshi Kawamura, Takashi Nagano, Takeshi Fukushima.



Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, 
USt.ID-Nr. DE 114 165 789
Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode, 
Heiko Lampert, Hiroshi Kawamura, Takashi Nagano, Takeshi Fukushima.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180220/9a231949/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asmELF.s
Type: application/octet-stream
Size: 1428 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180220/9a231949/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asmMSVC.s
Type: application/octet-stream
Size: 2371 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180220/9a231949/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Calling.PNG
Type: image/png
Size: 14041 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180220/9a231949/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CM_Elf_cpp.PNG
Type: image/png
Size: 12189 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180220/9a231949/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Interface_H.PNG
Type: image/png
Size: 2895 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180220/9a231949/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SimpleResult_H.PNG
Type: image/png
Size: 5952 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180220/9a231949/attachment-0003.png>

Hi Bjoern,

It looks like you are casting a regular function pointer (returned from
getFunctionAddress) to a virtual method pointer. This is undefined behavior.

The easiest way to achieve the effect you want would be to add a trampoline
to your source (or at the IR level):

extern "C" SimpleResult call_Interface_init(Interface *Instance) {
return
Instance->init(); }

Then you can just use:

auto CallInit
(SimpleResult(*)(Interface*))engine->getFunctionAddress("call_Interface_init");
CallInit(inter);

Cheers,
Lang.


On Tue, Feb 20, 2018 at 1:42 AM, via cfe-dev <cfe-dev at lists.llvm.org>
wrote:
> Still no progress with this problem. Only that non-member functions seems
> to be working...
> Also:
> Even when I set the target triple of the Module (when the file was parsed
> at runtime) to "COFF" nothing changes...
>
>
> From:        Bjoern Gaier/HE/HORIBA
> To:        llvm-dev at lists.llvm.org
> Cc:        cfe-dev at lists.llvm.org
> Date:        08.02.2018 12:28
> Subject:        Re: Calling virtual elf functions under windows ->
Adding
> ASM code
> ------------------------------
>
>
> Hello everyone,
>
> I'm sorry for "flooding" your inbox, but I wanted to extend
my message
> which is shown below. The problem is still not solved and I'm more
confused
> then before.
> I compiled the code - the one seen in the pictures  to elf bc and to msvc
> (pecoff) bc. Then I used llc to generate assembler output.
>
> In my opinion the involved functions are acting exactly the same. There
> are only some registers swapped. I should mention: when using the msvc bc
> code, then the calls via the interface are working.
>
> I attach the assembly code of the involved code to. Could please anyone
> explain me the difference, which could cause the crash?
>
> Kind regards
> Björn
>
>
>
>
> From:        Bjoern Gaier/HE/HORIBA
> To:        llvm-dev at lists.llvm.org, cfe-dev at lists.llvm.org
> Date:        07.02.2018 11:47
> Subject:        Calling virtual elf functions under windows
> ------------------------------
>
>
> Hello everyone reading this,
>
> I'm totally confused and need an explanation. I'm also not sure if
it's a
> clang or a LLVM subject.
>
> I'm working with Visual Studio 2015, LLVM 5.0.1 and Windows 7 64bit.
>
> I have a simple project. With 2 Header files and 1 cpp file.
> "Interface.h"
> This file defines a simple class with two pure virtual member functions.
>
> "SimpleResult.h"
> This file defines a struct holding an integer
>
> "CM_Elf.cpp"
> This file defines a class (CM_Elf) implementing the interface from
> Interface.h
> Also there is an instance of the class (named "elf").
>
> I compile the CM_Elf.cpp to a CM_Elf.bc file via clang-cl but with target
> "x86_64-pc-windows-elf"
>
>
> In another application I use LLVM to parse the BC file and use the
> ExecutionEngine to get some addresses.
> What I want to archive is:
> I want to call the implemented member functions of "elf".
>
> 1.) I execute all the global constructors collected by the ExecutionEngine
> -> The constructor of elf gets called
> 2.) I use ExecutionEngine to get the address of "elf"
> 3.) I use the interface to execute Interface::init
> -> Init gets called
> 4.) I use the interface to execute Interface::shutdown
> -> CRASH!
>
> When I swap the calls to init and shutdown, then everything works. So the
> virtual call to init seems to corrupt my stack - maybe it's the return
> value. Could it be a calling convention problem? But my target is still
> "windows" only msvc changed to elf...
> When I compile CM_Elf for target
"x86_64-pc-windows-msvc19.0.24215" then
> it works.
>
> When I get the address of CM_Elf::init and CM_Elf::shutdown via the
> ExecutionEngine and call them without using the virtual table, then again
> everything works.
>
> SO! Is it not possible to call virtual elf functions via there interface?
> But why does normal functions work? Also I reach the functions which are
> stored in the vTable of CM_Elf so the vTable is correct.
>
> I append some pictures of the code... I hope someone could help me with
> this.
>
> Kind regards
> Björn
>
>
>
>
>
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789
> Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode,
> Heiko Lampert, Hiroshi Kawamura, Takashi Nagano, Takeshi Fukushima.
>
>
>
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789
> Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode,
> Heiko Lampert, Hiroshi Kawamura, Takashi Nagano, Takeshi Fukushima.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180221/17692ea6/attachment.html>

Hi Björn,

It's correct - I tried casting the virtual function to a regular
function.
> But I also tried using the virtual function in the normal way.
>
Yes. If I understand your setup correctly you have a base class, Interface,
which is currently compiled into your application, and you are creating a
derived class in JIT'd code, and returning an Interface pointer to an
instance of the derived class. In this case you are probably running into
ABI incompatibility issues in the class layout between the ahead-of-time
and JIT'd code. Your ahead-of-time code will always have to call virtual
functions via trampolines. I would remove all references to the Interface
class from your main application (so that the compiler catches anyone who
tries to use it directly) and make it an opaque pointer type that you pass
into JIT'd code.

I don't understand why the generated assemblies are different. Are
they
> effected by the ELF and PE/COFF ABI? But I thought this problem would be
> solved thanks to the target-triple containing "windows".

I believe the code generator sometimes uses the format (ELF / COFF / MachO)
in making ABI decisions.

When I create the trampoline functions on the IR level - would there be
a
> way to inline them when used?

They can be inlined when called from other JIT'd code, but not when called
from ahead-of-time code.


The ideal solution to your situation would be to generate JIT'd code in the
same format as the ahead-of-time code. Then you can just use virtual
functions as normal. From memory there is some reason that you can't do
that though. Was it exception handling support?

Cheers,
Lang.

On Thu, Feb 22, 2018 at 12:00 AM, <bjoern.gaier at horiba.com> wrote:
> Hello Lang,
>
> It's correct - I tried casting the virtual function to a regular
function.
> But I also tried using the virtual function in the normal way.
>
> I don't understand why the generated assemblies are different. Are they
> effected by the ELF and PE/COFF ABI? But I thought this problem would be
> solved thanks to the target-triple containing "windows".
>
> When I create the trampoline functions on the IR level - would there be a
> way to inline them when used?
>
> Kind regards
> Björn
>
>
>
> From:        Lang Hames <lhames at gmail.com>
> To:        bjoern.gaier at horiba.com
> Cc:        LLVM Developers Mailing List <llvm-dev at lists.llvm.org>,
Clang
> Dev <cfe-dev at lists.llvm.org>
> Date:        21.02.2018 22:36
> Subject:        Re: [cfe-dev] Calling virtual elf functions under windows
> -> Adding ASM code
> ------------------------------
>
>
>
> Hi Bjoern,
>
> It looks like you are casting a regular function pointer (returned from
> getFunctionAddress) to a virtual method pointer. This is undefined
behavior.
>
> The easiest way to achieve the effect you want would be to add a
> trampoline to your source (or at the IR level):
>
> extern "C" SimpleResult call_Interface_init(Interface *Instance)
{ return
> Instance->init(); }
>
> Then you can just use:
>
> auto CallInit =
(SimpleResult(*)(Interface*))engine->getFunctionAddress("
> call_Interface_init");
> CallInit(inter);
>
> Cheers,
> Lang.
>
>
> On Tue, Feb 20, 2018 at 1:42 AM, via cfe-dev <*cfe-dev at
lists.llvm.org*
> <cfe-dev at lists.llvm.org>> wrote:
> Still no progress with this problem. Only that non-member functions seems
> to be working...
> Also:
> Even when I set the target triple of the Module (when the file was parsed
> at runtime) to "COFF" nothing changes...
>
>
> From:        Bjoern Gaier/HE/HORIBA
> To:        *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>
> Cc:        *cfe-dev at lists.llvm.org* <cfe-dev at lists.llvm.org>
> Date:        08.02.2018 12:28
> Subject:        Re: Calling virtual elf functions under windows ->
Adding
> ASM code
> ------------------------------
>
>
>
> Hello everyone,
>
> I'm sorry for "flooding" your inbox, but I wanted to extend
my message
> which is shown below. The problem is still not solved and I'm more
confused
> then before.
> I compiled the code - the one seen in the pictures  to elf bc and to msvc
> (pecoff) bc. Then I used llc to generate assembler output.
>
> In my opinion the involved functions are acting exactly the same. There
> are only some registers swapped. I should mention: when using the msvc bc
> code, then the calls via the interface are working.
>
> I attach the assembly code of the involved code to. Could please anyone
> explain me the difference, which could cause the crash?
>
> Kind regards
> Björn
>
>
>
>
> From:        Bjoern Gaier/HE/HORIBA
> To:        *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>,
> *cfe-dev at lists.llvm.org* <cfe-dev at lists.llvm.org>
> Date:        07.02.2018 11:47
> Subject:        Calling virtual elf functions under windows
> ------------------------------
>
>
> Hello everyone reading this,
>
> I'm totally confused and need an explanation. I'm also not sure if
it's a
> clang or a LLVM subject.
>
> I'm working with Visual Studio 2015, LLVM 5.0.1 and Windows 7 64bit.
>
> I have a simple project. With 2 Header files and 1 cpp file.
> "Interface.h"
> This file defines a simple class with two pure virtual member functions.
>
> "SimpleResult.h"
> This file defines a struct holding an integer
>
> "CM_Elf.cpp"
> This file defines a class (CM_Elf) implementing the interface from
> Interface.h
> Also there is an instance of the class (named "elf").
>
> I compile the CM_Elf.cpp to a CM_Elf.bc file via clang-cl but with target
> "x86_64-pc-windows-elf"
>
>
> In another application I use LLVM to parse the BC file and use the
> ExecutionEngine to get some addresses.
> What I want to archive is:
> I want to call the implemented member functions of "elf".
>
> 1.) I execute all the global constructors collected by the ExecutionEngine
> -> The constructor of elf gets called
> 2.) I use ExecutionEngine to get the address of "elf"
> 3.) I use the interface to execute Interface::init
> -> Init gets called
> 4.) I use the interface to execute Interface::shutdown
> -> CRASH!
>
> When I swap the calls to init and shutdown, then everything works. So the
> virtual call to init seems to corrupt my stack - maybe it's the return
> value. Could it be a calling convention problem? But my target is still
> "windows" only msvc changed to elf...
> When I compile CM_Elf for target
"x86_64-pc-windows-msvc19.0.24215" then
> it works.
>
> When I get the address of CM_Elf::init and CM_Elf::shutdown via the
> ExecutionEngine and call them without using the virtual table, then again
> everything works.
>
> SO! Is it not possible to call virtual elf functions via there interface?
> But why does normal functions work? Also I reach the functions which are
> stored in the vTable of CM_Elf so the vTable is correct.
>
> I append some pictures of the code... I hope someone could help me with
> this.
>
> Kind regards
> Björn
>
>
>
>
>
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789
> Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode,
> Heiko Lampert, Hiroshi Kawamura, Takashi Nagano, Takeshi Fukushima.
>
>
>
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789
> Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode,
> Heiko Lampert, Hiroshi Kawamura, Takashi Nagano, Takeshi Fukushima.
>
>
> _______________________________________________
> cfe-dev mailing list
> *cfe-dev at lists.llvm.org* <cfe-dev at lists.llvm.org>
> *http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev*
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
>
>
>
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789
> Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode,
> Heiko Lampert, Hiroshi Kawamura, Takashi Nagano, Takeshi Fukushima.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180222/453be0ad/attachment.html>