search for: executeprogram

I am currently running on a Mac OSX 10.3.8 and trying to compile llvm-1.4 on my local machine for Prof. Adve's class. I am using Apple's provided gcc 3.3 as my compiler. I ran into this compile error: SysUtils.c: In function `executeProgram': SysUtils.c:119: error: `RTLD_NEXT' undeclared (first use in this function) SysUtils.c:119: error: (Each undeclared identifier is reported only once SysUtils.c:119: error: for each function it appears in.) make[2]: *** [/Users/senatorned/llvm/tools/llee/Debug/SysUtils.lo] Error 1 make[1]:...

...2005, Kevin J. Stephano wrote: > I am currently running on a Mac OSX 10.3.8 and trying to > compile llvm-1.4 on my local machine for Prof. Adve's class. > > I am using Apple's provided gcc 3.3 as my compiler. > > I ran into this compile error: > SysUtils.c: In function `executeProgram': > SysUtils.c:119: error: `RTLD_NEXT' undeclared (first use in > this function) > SysUtils.c:119: error: (Each undeclared identifier is reported > only once > SysUtils.c:119: error: for each function it appears in.) > make[2]: *** > [/Users/senatorned/llvm/tools/llee/D...

...o make a difference. It seems that when bugpoint is run with --run-jit, the linker args are not passed to gcc (from tools/bugpoint/ExecutionDriver.cpp) : if (InterpreterSel == RunLLC || InterpreterSel == RunCBE || InterpreterSel == CBE_bug || InterpreterSel == LLC_Safe) RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, OutputFile, AdditionalLinkerArgs, SharedObjs, Timeout, MemoryLimit); else RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, OutputFile, std::ve...

...e. These changes shouldn't conflict with yours. revision 75292 revision 75293 bugpoint now works for remote ARM if you run it directly from the command line. It doesn't work correctly when invoked from the test makefile because envvar PWD is being set to /bin/pwd and so causing GCC::ExecuteProgram to do the wrong thing. I'm not sure what is going on with that, perhaps something in the makefile hierarchy is setting PWD to /bin/pwd instead of executing that command to get the pwd. I will investigate. David On Jul 10, 2009, at 1:45 PM, Viktor Kutuzov wrote: > David, > > P...

...t when bugpoint is run with > --run-jit, the linker args are not passed to gcc (from > tools/bugpoint/ExecutionDriver.cpp) : > > if (InterpreterSel == RunLLC || InterpreterSel == RunCBE || > InterpreterSel == CBE_bug || InterpreterSel == LLC_Safe) > > RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, > OutputFile, AdditionalLinkerArgs, > SharedObjs, > Timeout, MemoryLimit); > > else > > > RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, >...

Hello, David > bugpoint now works for remote ARM if you run it directly from the > command line. It doesn't work correctly when invoked from the test > makefile because envvar PWD is being set to /bin/pwd and so causing > GCC::ExecuteProgram to do the wrong thing. I'm not sure what is going > on with that, perhaps something in the makefile hierarchy is setting > PWD to /bin/pwd instead of executing that command to get the pwd. I > will investigate. This might be propagated from Makefile.config. I think it's better to f...

Hi, LLI now supports -load but bugpoint LLI:ExecuteProgram() still assumes that it doesn't. The attached patch makes bugpoint pass -load arguments to LLI and lets one to use bugpoint with programs that depend on native shared libraries. best regargs, Timo Lindfors -------------- next part -------------- A non-text attachment was scrubbed... Name: llv...

...en bugpoint is run > with --run-jit, the linker args are not passed to gcc (from tools/ > bugpoint/ExecutionDriver.cpp) : > > if (InterpreterSel == RunLLC || InterpreterSel == RunCBE || > InterpreterSel == CBE_bug || InterpreterSel == LLC_Safe) > > RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, > OutputFile, AdditionalLinkerArgs, > SharedObjs, > Timeout, MemoryLimit); > > else > > > RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, >...

...n with --run-jit, the linker args are not passed to gcc (from >> tools/bugpoint/ExecutionDriver.cpp) : >> >> if (InterpreterSel == RunLLC || InterpreterSel == RunCBE || >> InterpreterSel == CBE_bug || InterpreterSel == LLC_Safe) >> >> RetVal = AI->ExecuteProgram(BitcodeFile, InputArgv, InputFile, >> OutputFile, AdditionalLinkerArgs, >> SharedObjs, >> Timeout, MemoryLimit); >> >> else >> >> >> RetVal = AI->ExecuteProgram(BitcodeFile, In...

On Tue, Oct 28, 2008 at 12:17 PM, Prakash Prabhu <prakash.prabhu at gmail.com> wrote: > Generating reference output from raw program: <cbe><gcc> > Error running tool: [snip] > /tmp/cc08IpX8.o: In function `SyLoadModule': > bugpoint-test-program.bc.cbe.c:(.text+0x25705): undefined reference to > `dlopen' [snip] This is saying that compilation with CBE is

...with yours. > > revision 75292 > revision 75293 > > bugpoint now works for remote ARM if you run it directly from the > command line. It doesn't work correctly when invoked from the test > makefile because envvar PWD is being set to /bin/pwd and so causing > GCC::ExecuteProgram to do the wrong thing. I'm not sure what is going > on with that, perhaps something in the makefile hierarchy is setting > PWD to /bin/pwd instead of executing that command to get the pwd. I > will investigate. > > David > > > On Jul 10, 2009, at 1:45 PM, Viktor...

Hi Chris, > Also note, LLVM 1.4 will be released in the next few days, so if waiting is > an option, you might choose to do so. Alright, I've got llvm and llvm-gcc from RELEASE_14 cvs and tried building it under cygwin. 1) The first problem is with llvm in SysUtils.c: int executeProgram(const char *filename, char *const argv[], char *const envp[]) { ................ execveTy execvePtr = (execveTy) dlsym(RTLD_NEXT, "execve"); ..... } RTLD_NEXT is not defined in cygwin headers. 2) cfontend built ok 3) full llvm failed to build: make[3]: Entering directory `/cygdrive/...

Hi, I have a program that runs when statically compiled using llc and gcc but crashes with a segmentation fault when run with lli. I am trying to debug it with bugpoint and the initial part of bugpoint seems to be suggesting that I am somehow missing the linking with the libraries having dlsym/dlopen although I am passing it to lli : *$ bugpoint -run-jit

...our Fortran libraries. Is there a way to do this via bugpoint's command-line interface or do I have to hack bugpoint's source? I can see how I might make the GCC class a subclass of some ReferenceCompiler class and then abstract our compiler's interface in the same way (reimplementing ExecuteProgram and friends. -Dave

David, Please find attached 2 diffs. Please notice that RemoteRunSafely.sh may get moved to the test suite sub-tree. We have targeted different areas fso far which is great. What's your plan? I have been thinking of using -run-custom and -safe-run-custom argumants for the cross-tools to keep bugpoint out of knowing any target details ans such. Best regards, Viktor ----- Original Message

Hi Viktor, I did not see your patches, can you send them again. Here are the changes that I have made that seem to get remote execution working for bugpoint. I have not yet changed the test system to provide -remote- client and -remote-port. David -------------- next part -------------- A non-text attachment was scrubbed... Name: patch2 Type: application/octet-stream Size: 1906 bytes Desc: