search for: mainaddr

...Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote: > I found out the problem. Looks like I can not rely on argv[0] to contain the > full path of the executable always. Yeah, that's what I was thinking. > Can I rely on: > static Path GetMainExecutable(const char *argv0, void *MainAddr); Clang relies on it. According to http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/driver.cpp MainAddr can be any symbol in the binary. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

...amespace clang::driver; extern "C" int yipee(int val) { fprintf(stderr, "yipee!"); return 1; } llvm::sys::Path GetExecutablePath(const char *Argv0) { // This just needs to be some symbol in the binary; C++ doesn't // allow taking the address of ::main however. void *MainAddr = (void*) (intptr_t) GetExecutablePath; return llvm::sys::Path::GetMainExecutable(Argv0, MainAddr); } int Execute(llvm::Module *Mod, char * const *envp) { llvm::InitializeNativeTarget(); std::string Error; llvm::OwningPtr<llvm::ExecutionEngine> EE( llvm::ExecutionEngine::createJIT(Mod...

...forms can't implement GetMainExecutable // without being given the address of a function in the main executable). llvm::sys::Path GetExecutablePath(const char *Argv0) { // This just needs to be some symbol in the binary; C++ doesn't // allow taking the address of ::main however. void *MainAddr = (void*) (intptr_t) GetExecutablePath; return llvm::sys::Path::GetMainExecutable(Argv0, MainAddr); } static int Execute(llvm::Module *Mod, char * const *envp) { llvm::InitializeNativeTarget(); std::string Error; OwningPtr<llvm::ExecutionEngine> EE( llvm::ExecutionEngine::create...

I found out the problem. Looks like I can not rely on argv[0] to contain the full path of the executable always. Can I rely on: static Path GetMainExecutable(const char *argv0, void *MainAddr); is it Cross-platform? What to pass for second parameter here. C++ forbids taking address of "main", and the "Main" of CompilerDriver is in a shared object here. - Sanjiv Sanjiv Gupta wrote: > The driver behaves differently when I run it by specifying absolute path >...

I tried what you said, now I get: LLVM ERROR: Program used external function 'yipee' which could not be resolved! Stack dump: 0. Running pass 'X86 Machine Code Emitter' on function '@main' did not even get as far as a breakpoint. Óscar Fuentes wrote: > > gafferuk <gafferuk at gmail.com> writes: > >> Im confused. The function i wish to call is

The driver behaves differently when I run it by specifying absolute path than when I run it with relative path. See example Relative: i00202 at ubuntu:/tmp$ mcc16 --save-temps -dry-run hello.c./clang-cc -I ./include -triple=pic16- -emit-llvm-bc hello.c -o hello.bc-pqDR1Y llvm-ld -link-as-library hello.bc-pqDR1Y -o tmp.bc-M1Rwip llc -march=pic16 -f tmp.bc-M1Rwip -o tmp.s-DcVczP gpasm -I ./inc

gafferuk <gafferuk at gmail.com> writes: > Im confused. The function i wish to call is a return type of int. > Im calling it with int dd = yipee(1); > > What's wrong? Declare the function: int yipee(int); int main() { int dd = yipee(1); return 0; } If that still crashes, put a breakpoint on `yipee' and see if the execution gets there, if the argument is

why llvm contains IntrusiveRefCntPtr instead of using only std::shared_ptr? IntrusiveRefCntPtr widely used in llvm and clang source code. Due to better performance? for example in main func of clang frontend: int cc1_main(ArrayRef<const char *> Argv, const char *Argv0, void *MainAddr) { ensureSufficientStack(); std::unique_ptr<CompilerInstance> Clang(new CompilerInstance()); IntrusiveRefCntPtr<DiagnosticIDs> DiagID(new DiagnosticIDs()); IntrusiveRefCntPtr<DiagnosticOptions> DiagOpts = new DiagnosticOptions(); --  Best wishes, Ivan Kush

...t; >> I found out the problem. Looks like I can not rely on argv[0] to contain the >> full path of the executable always. >> > > Yeah, that's what I was thinking. > > >> Can I rely on: >> static Path GetMainExecutable(const char *argv0, void *MainAddr); >> > > Clang relies on it. According to > > http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/driver.cpp > > MainAddr can be any symbol in the binary. > >

This is a proposed patch to enhance FileSystem.h to add functionality (getting and setting permission bits and mapping an unmapping files). This implementation follows the N3365 proposal regarding permission bits. This functionality is needed for my next patch which will implement llvm/include/Support/FileOutputBuffer.h which is needed by lld. -------------- next part -------------- A

On Fri, May 18, 2012 at 3:07 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> +  error_code ec = sys::fs::status(filePathTwine, stat); > > stat is undefined if ec isn't success. ec will be success even in the case of > file_not_found. Actually I was wrong. The Windows and UNIX implementation disagree on this point. I'm going to change it to match

I ran into an LLVM/Clang crash when attempting to do the following: 1. Build Clang from the release/9.x branch source. 2. Use the Clang from (1) to build clangd on the release/9.x branch, with LLVM_ENABLE_MODULES=On. I wrote a script to reproduce the crash: https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608 At the above URL, you'll find a script `repro.sh` that reproduces

...pre-3.9/2016-07-17-22-54-42-1cb1a4c-master/llvm/tools/cfe/lib/FrontendTool/ExecuteCompilerInvocation.cpp:241 #22 0x0000000000c33bc8 in cc1_main (Argv=..., Argv0=0x7fffffffe3f9 "/work/Abe/non-backup-worthy/build_dirs/Clang/pre-3.9/2016-07-17-22-54-42-1cb1a4c-master/tmp/clang", MainAddr=0xc26010 <GetExecutablePath(char const*, bool)>) at /work/Abe/non-backup-worthy/build_dirs/Clang/pre-3.9/2016-07-17-22-54-42-1cb1a4c-master/llvm/tools/cfe/tools/driver/cc1_main.cpp:116 #23 0x0000000000c27c2a in ExecuteCC1Tool (argv=..., Tool=...) at /work/Abe/non-backup-worthy/b...

...ool/ExecuteCompilerInvocation.cpp:175 >>>>> #19 0x0000000000a99618 in cc1_main (ArgBegin=0x7fffffffaf10, >>>>> ArgEnd=0x7fffffffb108, Argv0=0x3cebaf8 >>>>> "/prj/qct/sunray-austin/scratch/slarin/qdsp6_hex/bin/qc/bin/clang", >>>>> MainAddr=0xaa4654) >>>>> at >>>>> /local/mnt/workspace/slarin/tools/llvm-mainline- >>>> merged/tools/clang/tools/dri >>>>> ver/cc1_main.cpp:165 >>>>> #20 0x0000000000aa5e77 in main (argc_=65, argv_=0x7fffffffc058) at >>>>&g...

Dear all, In the process of trying to add optimization for better layout of global variables, I have run up against a roadblock: I don`t seem to be able to sort the contents of a "SymbolTableListTraits<GlobalVariable>" -- or even swap two elements in that list -- without causing LLVM to crash. I have tried writing a comparator class and then using "llvm::iplist<