On Nov 11, 2008, at 2:19 PM, Peter Shugalev wrote:> Hi, > > Owen Anderson wrote: >>> I can see only one reason for such dependence: inclusion of system >>> headers in /usr/include. If I compile llvm-gcc with predefined set >>> of >>> Linux headers (the way cross-compilers are usually made) will the IR >>> output be the same no matter which platform is used for compilation? >>> >> >> No. Consider use of sizeof(), ABI issues, etc. > > Ooh, now I see llvm-gcc is not cross-compiler in the terms of GCC. > Okay, > but what if I actually compile LLVM-gcc as cross-compiler for 64-bit > x86-64 Linux. Then it is guaranteed to produce identical output on all > the systems. > > Question is: how the resulting LLVM IR will run on 32-bit machine? > Should I create stubs for all called functions to convert between 32 > and > 64-bit pointers? Or it won't run at all?If you configure it as a cross-compiler for 64-bit x86 Linux and feed it the appropriate header files, it will produce the same output on any platform. However, that output will not be executable on most platforms, just on 64-bit x86 Linux. The problems go beyond pointer size. The size of int is implementation dependent, etc. The layout and padding of structs is implementation dependent. While all implementations on a given target-triple will generally agree to ensure binary compatibility, there is no guarantee of things being the same once you go to another target-triple. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2624 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081111/8771b027/attachment.bin>
Owen Anderson wrote:> If you configure it as a cross-compiler for 64-bit x86 Linux and feed it > the appropriate header files, it will produce the same output on any > platform. However, that output will not be executable on most > platforms, just on 64-bit x86 Linux. The problems go beyond pointer > size. The size of int is implementation dependent, etc. The layout and > padding of structs is implementation dependent. While all > implementations on a given target-triple will generally agree to ensure > binary compatibility, there is no guarantee of things being the same > once you go to another target-triple.Do you mean that cross-target execution CAN break on examples like this one? [eventually on this example it doesn't] struct X { void *a; int b; } x; *(int *) ((char *)&x + sizeof(void*)) = 1; However this one will work because getelementptr is wise enough: struct X { void *a; int b; } x; x.b = 1; Now I avoid the former code sample and likes of it and figure out every problem of alignment. Do I have the chance to run the same LLVM IR on platform of different bitness? BTW: is there a plan to introduce expressions as constants (including sizeof() operation) in IR? It will rule out some of llvm-gcc compile time optimizations but the resulting code will be much more portable. -- Best Regards Peter Shugalev
On Nov 11, 2008, at 3:51 PM, Peter Shugalev wrote:> Owen Anderson wrote: >> If you configure it as a cross-compiler for 64-bit x86 Linux and >> feed it >> the appropriate header files, it will produce the same output on any >> platform. However, that output will not be executable on most >> platforms, just on 64-bit x86 Linux. The problems go beyond pointer >> size. The size of int is implementation dependent, etc. The >> layout and >> padding of structs is implementation dependent. While all >> implementations on a given target-triple will generally agree to >> ensure >> binary compatibility, there is no guarantee of things being the same >> once you go to another target-triple. > > Do you mean that cross-target execution CAN break on examples like > this > one? [eventually on this example it doesn't] > > struct X { > void *a; > int b; > } x; > > *(int *) ((char *)&x + sizeof(void*)) = 1; >What about something much simpler: memcpy'ing an array of structs around. The number of bytes to be memcpy'd is dependent on the padding of the struct. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2624 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081111/1c65ef3d/attachment.bin>