search for: __main

...} int %main(int %argc, sbyte** %argv) { entry: %data_b = alloca int ; <int*> [#uses=2] %data_c = alloca int ; <int*> [#uses=1] %data_d = alloca int ; <int*> [#uses=3] %data_e = alloca int ; <int*> [#uses=2] %data_f = alloca int ; <int*> [#uses=2] call void %__main( ) store int 2, int* %data_b store int 3, int* %data_c store int 4, int* %data_d store int 5, int* %data_e store int 6, int* %data_f switch int %argc, label %switchexit [ int 3, label %label.3 int 2, label %then.2 int 1, label %label.1 int 0, label %endif.2 ] label.1: ; preds =...

Oh, I appologize that I should not have asked about __main() ---- it appears in FAQ. But the question remains that why call to __main() can alias stack location? I think the memory location pointed by data_X pointers are not visible to __main(). In comparison, calls to printf() do not have similar effect. On 5/14/06, Nai Xia <nelson.xia at gmail.com...

...> > You are definitely a good man. :) > > I feel so much to learn. > > Happy to help! > > -Chris > > > On Monday 15 May 2006 04:07, you wrote: > >> On Sun, 14 May 2006, Nai XIA wrote: > >>> Oh, I appologize that I should not have asked about __main() ---- it appears > >>> in FAQ. > >>> But the question remains that why call to __main() can alias stack location? > >>> I think the memory location pointed by data_X pointers are not visible to > >>> __main(). > >>> In comparison, calls t...

...t;> >>>> Happy to help! >>>> >>>> -Chris >>>> >>>>> On Monday 15 May 2006 04:07, you wrote: >>>>>> On Sun, 14 May 2006, Nai XIA wrote: >>>>>>> Oh, I appologize that I should not have asked about __main() ---- it appears >>>>>>> in FAQ. >>>>>>> But the question remains that why call to __main() can alias stack location? >>>>>>> I think the memory location pointed by data_X pointers are not visible to >>>>>>> __main...

...a good man. :) >>> I feel so much to learn. >> >> Happy to help! >> >> -Chris >> >>> On Monday 15 May 2006 04:07, you wrote: >>>> On Sun, 14 May 2006, Nai XIA wrote: >>>>> Oh, I appologize that I should not have asked about __main() ---- it appears >>>>> in FAQ. >>>>> But the question remains that why call to __main() can alias stack location? >>>>> I think the memory location pointed by data_X pointers are not visible to >>>>> __main(). >>>>> In comp...

...uch to learn. > >> > >> Happy to help! > >> > >> -Chris > >> > >>> On Monday 15 May 2006 04:07, you wrote: > >>>> On Sun, 14 May 2006, Nai XIA wrote: > >>>>> Oh, I appologize that I should not have asked about __main() ---- it appears > >>>>> in FAQ. > >>>>> But the question remains that why call to __main() can alias stack location? > >>>>> I think the memory location pointed by data_X pointers are not visible to > >>>>> __main(). > &gt...

Dear All, Are global static constructors called before main() in LLVM these days using some behind-the-scenes magic that is not explicit in the LLVM bitcode? In older versions of LLVM, llvm-gcc added an explicit function call to __main() as the first instruction in main(); __main() would call all global static constructors. It seems __main() is now gone. I've got a transform that instruments all code in a program (including constructors) with calls to a run-time library. I need to make sure that the call to the run-time...

...confirmed what I was trying to do, but when I compile: ----------------------- #include <stdio.h> int main(int argc, char *argv[]) { printf("yo\n"); return 0; } ----------------------- without "-c" (llvm-gcc t1.c -o t1) the dissassembled bytecode does not call __main: ----------------------- ; ModuleID = '<stdin>' target endian = little target pointersize = 32 target triple = "i686-pc-linux-gnu" deplibs = [ "c", "crtend" ] %struct..TorRec = type { int, void ()* } %struct.TorRec = type { int, void ()* } %.str_...

On Sun, Feb 26, 2006 at 10:00:18PM -0800, Wink Saville wrote: > Thanks for the info, you've confirmed what I was trying to do, but when > I compile: [snip] > without "-c" (llvm-gcc t1.c -o t1) the dissassembled bytecode does not > call __main: __main() is used to run static constructors and destructors, so if you're compiling without -c, LLVM knows all the files you're compiling and if there are no static constructors, __main() is not necessary (or if it's there, it's empty, and can be inlined into a no-op). [snip] &gt...

...each initializer to run. > Right, I saw that. I just didn't see anything from main() calling those functions, which led me to believe that something else is calling those functions before main(). >> In older versions of LLVM, llvm-gcc added an explicit function >> call to __main() as the first instruction in main(); __main() would >> call >> all global static constructors. It seems __main() is now gone. >> > > Yep, __main is now gone, llvm.globalctors is king. :) > I assume putting my constructor at the head of the llvm.globalctors lis...

Hello, Ted > __main is supposed to be inside hello.bc, so why can�t lli find it? No, it shouldn't be there. On targets, which lacks init sections (for example, all win-based, like mingw & cygwin) __main is used to call static constructors and relevant stuff. The call to __main is assembled early in the main r...

...g some behind-the-scenes magic that is not explicit in the LLVM > bitcode? It is explicit in the bitcode. You should see an llvm.globalctors global array that has function pointers for each initializer to run. > In older versions of LLVM, llvm-gcc added an explicit function > call to __main() as the first instruction in main(); __main() would > call > all global static constructors. It seems __main() is now gone. Yep, __main is now gone, llvm.globalctors is king. :) -Chris

Hi LLVMDev, The GCC frontend for LLVM inserts a call to a __main() in the main() function. Whats the purpose of this? And which LLVM library do I need to link to satisfy the reference? Thanks, Rahul

Hello, When I compile a "hello.c" program with a printf in "main" and use llvm-gcc with a "-c" option: llvm-gcc -c t1.c -o t1.bc and then try to compile t1.bc to native using llc & gcc I get a call to "__main" which is undefined. If I don't use the "-c" option: llvm-gcc t1.c -o t1 I don't get a reference to "__main" and I can compile to native without problem. Also, I created some simple modules without a "main" and using the "-c" option and...

...t.bc->file.opt.c. Now, I want to use normal gcc to compile file.opt.c into an executable. However, I'm getting the following errors: test.opt.c:89: warning: conflicting types for built-in function 'malloc' test.opt.o(.text+0xe7): In function `main': : undefined reference to `__main' collect2: ld returned 1 exit status make: *** [test.opt.exe] Error 1 ------ I think the problem with main and __main is that I need to link in some LLVM runtime libraries. So, I tried to link in crtend (which defines __main). However, I get the following error: /home/testbed1/lefever/wo...

...wrote: > Hello, > > When I compile a "hello.c" program with a printf in "main" and use > llvm-gcc with a "-c" option: > > llvm-gcc -c t1.c -o t1.bc > > and then try to compile t1.bc to native using llc & gcc I get a call > to "__main" which is undefined. > > If I don't use the "-c" option: > > llvm-gcc t1.c -o t1 > > I don't get a reference to "__main" and I can compile to native > without problem. Also, I created some simple modules without a "main" > and...

...--- LLVM code -------------- deplibs = [ "stdc++", "c", "crtend" ] %.str_1 = internal constant [13 x sbyte] c"hello world\0A\00"; <[13 x sbyte]*> [#uses=1] implementation ; Functions: declare int %printf(sbyte*, ...) int %main() { entry: call void %__main( ) %tmp.0 = call int (sbyte*, ...)* %printf( sbyte* getelementptr ([13 x sbyte]* %.str_1, int 0, int 0) ); <int> [#uses=0] ret int 0 } declare void %__main() ------------- End LLVM code ----------- which in turn produces the following assembly code: ------------- Assembly code ------------...

...nd third lines generate the C code and compile it into a final executable. If that doesn't work, please let me know. > > test.opt.c:89: warning: conflicting types for built-in function 'malloc' > test.opt.o(.text+0xe7): In function `main': > : undefined reference to `__main' > collect2: ld returned 1 exit status > make: *** [test.opt.exe] Error 1 > > ------ > > I think the problem with main and __main is that I need to link in some > LLVM runtime libraries. So, I tried to link in crtend (which defines > __main). However, I get the fol...

...c++", "c", "crtend" ] > %.str_1 = internal constant [13 x sbyte] c"hello world\0A\00"; <[13 x > sbyte]*> [#uses=1] > > implementation ; Functions: > > declare int %printf(sbyte*, ...) > > int %main() { > entry: > call void %__main( ) > %tmp.0 = call int (sbyte*, ...)* %printf( sbyte* getelementptr ([13 x > sbyte]* %.str_1, int 0, int 0) ); <int> [#uses=0] > ret int 0 > } > > declare void %__main() > ------------- End LLVM code ----------- > > which in turn produces the following assembly co...

...s, which led me to believe that something else is calling > those > functions before main(). Yep, the code generators handle them magically, usually by emitting something to a .init section. >>> In older versions of LLVM, llvm-gcc added an explicit function >>> call to __main() as the first instruction in main(); __main() would >>> call >>> all global static constructors. It seems __main() is now gone. >>> >> >> Yep, __main is now gone, llvm.globalctors is king. :) >> > I assume putting my constructor at the head of the l...