[LLVMdev] LLVM JIT on a Baremetal x86 Machine !!!

Tue Nov 8 07:41:05 PST 2011

Hi James,

I have two questions for you.

Firstly, what is the role of 'module' in init.cc? I can see that its 
being treated like it is a 'bytecode' file, as we open it and then pass 
it to the ByteCoder and eventually construct llvm module from it.

Like In file init.cc, line:121
     FILE *stream  = fopen("/module", "rb");
     ...
     fread(c, 1, sz, stream);
     ...
     Bytecoder bc(std::cout, c, sz, &errors);
     ...

The Open SysCall returns a pointer to the 'Special File' that was 
created in 'InitialiseSpecialFiles':
In file SpecialFile.cc, line:204, its defined as a special file:
     static SpecialModule modl("/module");
     s_files[3] = &modl;

Is this 'module' somehow related to 'KERNEL_HBC' that we specified earlier ?
If yes then how I am getting the size of this special file to be zero, 
whereas the size of my 'hello_world.hbc' is 225 bytes.
If no, then what is it ?

Secondly You have mentioned on the Horizon wiki:
"The build process will produce a version of horizon statically linked 
with code that provides enough of a UNIX environment for LLVM and 
libstdc++ to function"

Could you please shed some more light on this aspect (Some links, if 
possible), on how you have accomplished this ?
I am not an expert in these aspects, your help in this regard will be 
highly appreciated.
--
Hamayun

P.S. I am also attaching files with a basic lseek (SyscallLSeek) 
implementation and an execution log showing the current failure 
("Invalid magic number reading bytecode file.").

On 11/03/2011 05:37 PM, James Molloy wrote:
> Hi Mian,
>
> Looking at the runlog, everything seems fine until LLVM attempts to use lseek() on a file.
>
> You see the PANIC because Horizon hasn't implemented lseek yet.
>
> Obviously the version of GlibC I was using does not use lseek in that circumstance, but yours does. You just need to implement lseek :)
>
> Cheers,
>
> James
>
> -----Original Message-----
> From: Mian M. Hamayun [mailto:mian-muhammad.hamayun at imag.fr]
> Sent: 03 November 2011 15:59
> To: James Molloy
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] LLVM JIT on a Baremetal x86 Machine !!!
>
> Hello James,
>
> I hope I will not be disturbing you too much. As I mentioned earlier, I
> am interested in unhosted (baremetal) x86 environment for LLVM JIT.
> Let me come to the point straight.
>
> I have set the KERNEL_HBC as:
> set(KERNEL_HBC
> "/altamaha/home3/hamayun/workspace/horizon/code-samples/hello_world.hbc")
>
> And Compiled the Horizon Sources. Compilation works fine and it creates
> the cd.img as you described on:
> http://www.quokforge.org/projects/horizon/wiki/Building
>
> See the attached "Horizon_Build.Log" file for more details.
>
> Now when I load this 'image' using qemu; It gives me the following error:
> horizon: PANIC: syscall 0x8 (lseek) @ 0xc0f530
>
> See the attached "Horizon_Qemu_Run.log" file for more details.
>
> I guess I am not setting the KERNEL_HBC variable properly.
> Could you give me an idea of whats going wrong here ?
>
> Thanks a lot,
> Hamayun
>
>
> On 10/28/2011 02:46 PM, Mian M. Hamayun wrote:
>> Hi James,
>>
>> Thanks A lot. I have downloaded the source code and I am currently
>> looking into it.
>> I will get back to you if I need some clarifications.
>>
>> Thanks Again,
>> --
>> Hamayun
>>
>> On 10/26/2011 03:20 PM, James Molloy wrote:
>>> Hi Mian,
>>>
>>> I have actually done this. I wrote a safe bytecode which compiles down to
>>> LLVM IR, and had baremetal applications running using it.
>>>
>>> Code here:
>>> http://www.quokforge.org/projects/horizon/repository/revisions/master/show/h
>>>
>>> orizon/Baremetal
>>>
>>> My method was to compile for hosted linux, then modify the resulting
>>> code to
>>> run baremetal. For me, this involved rewriting "syscall" instructions to
>>> "int $X" as everything was running in supervisor mode and "syscall" only
>>> works from user mode.
>>>
>>> Apart from that there's just a load of stubs to implement. Pretty easy
>>> really.
>>>
>>> Cheers,
>>>
>>> James
>>>
>>>
>>> -----Original Message-----
>>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
>>> Behalf Of Mian M. Hamayun
>>> Sent: 26 October 2011 14:12
>>> To: llvmdev at cs.uiuc.edu
>>> Subject: [LLVMdev] LLVM JIT on a Baremetal x86 Machine !!!
>>>
>>> Dear All,
>>>
>>> I have tested a few examples of LLVM-JIT Framework on Linux x86 Machine.
>>> So generating functions on the fly and then executing them is OK on
>>> linux i.e. i686-pc-linux-gnu
>>>
>>> My question is:
>>>
>>> Can we use the LLVM-JIT on a baremetal x86 machine ? Actually my target
>>> is a virtual machine, and I need some dynamic code generation support. I
>>> intend to use LLVM-JIT (if possible) for this purpose.
>>>
>>> Furthermore if it is possible, then how much effort would be required ?
>>> And where should I start looking for doing this kind of port.
>>>
>>> Thanks for your help.
>>>
>>> --
>>> Hamayun
>>> Grenoble, France.
>>>
>>>
>>>
>>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run.log
Type: text/x-log
Size: 4198 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111108/75437bce/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SpecialFile.cc
Type: text/x-c++src
Size: 10089 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111108/75437bce/attachment.cc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: syscallHandlers.cc
Type: text/x-c++src
Size: 11674 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111108/75437bce/attachment-0001.cc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3781 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111108/75437bce/attachment-0001.bin>