search for: __morestack

...mail.com> wrote: > What is the linker command line buidling liblldb.so? is libgcc.a passed in? > There is no difference in the linker command for liblldb.so or bin/lldb between the ld.bfd and ld.gold cases, and neither links libgcc.a that I can see. The difference appears to be that the __morestack symbol is weak in the ld.gold liblldb.so case (and simply doesn't appear in the resulting bin/lldb presumably because libgcc.a is not linked): $ nm lib/liblldb.so.3.9.1 | grep morestack w __morestack whereas it is an undef in the ld.bfd case: $ nm lib/liblldb.so | grep mores...

In uint64_t RTDyldMemoryManager::getSymbolAddressInProcess(const std::string &Name) { there is reference to morestack: #if defined(__i386__) || defined(__x86_64__) // __morestack lives in libgcc, a static library. if (&__morestack && Name == "__morestack") return (uint64_t)&__morestack; #endif #endif // __linux__ && __GLIBC__ On Mon, Oct 3, 2016 at 3:32 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Mon...

...b.so? is libgcc.a passed >>> in? >>> >> >> There is no difference in the linker command for liblldb.so or bin/lldb >> between the ld.bfd and ld.gold cases, and neither links libgcc.a that I can >> see. >> >> The difference appears to be that the __morestack symbol is weak in the >> ld.gold liblldb.so case (and simply doesn't appear in the resulting >> bin/lldb presumably because libgcc.a is not linked): >> >> $ nm lib/liblldb.so.3.9.1 | grep morestack >> w __morestack >> >> whereas it is a...

...t;> >>>> >>>> There is no difference in the linker command for liblldb.so or bin/lldb >>>> between the ld.bfd and ld.gold cases, and neither links libgcc.a that I can >>>> see. >>>> >>>> The difference appears to be that the __morestack symbol is weak in the >>>> ld.gold liblldb.so case (and simply doesn't appear in the resulting >>>> bin/lldb presumably because libgcc.a is not linked): >>>> >>>> $ nm lib/liblldb.so.3.9.1 | grep morestack >>>> w __mor...

...tead? Only if 'ninja install` would reference the two executables. If that's case, and I haven't gotten that far yet due to ThinLTO not finishing, I'll consider copying those to the local build tree first. > Can you nm the .so files in your lib dir and see if any reference > __morestack? $ for so in lib/*.so; do echo $so ; nm $so|grep __morestack;done lib/BugpointPasses.so lib/libclang.so lib/libgomp.so lib/libiomp5.so lib/liblldb.so U __morestack lib/libLTO.so lib/libomp.so lib/LLVMgold.so lib/LLVMHello.so lib/LLVMPolly.so Looks like liblldb.so does. Does that...

...erence the two executables. If that's >> case, and I haven't gotten that far yet due to ThinLTO not finishing, >> I'll consider copying those to the local build tree first. >> >> > Can you nm the .so files in your lib dir and see if any reference >> > __morestack? >> >> $ for so in lib/*.so; do echo $so ; nm $so|grep __morestack;done >> lib/BugpointPasses.so >> lib/libclang.so >> lib/libgomp.so >> lib/libiomp5.so >> lib/liblldb.so >> U __morestack >> lib/libLTO.so >> lib/libomp.so...

...lt; llvm-dev at lists.llvm.org> wrote: > Aha - finally reproduced! The difference is using ld.bfd not ld.gold. With > that I get the same failure (using 3.9 to build 3.9 sources): > > /usr/local/google/home/tejohnson/binutils_build/install/bin/ld: > bin/lldb-3.9.1: hidden symbol `__morestack' in > /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a(morestack.o) is referenced by > DSO > /usr/local/google/home/tejohnson/binutils_build/install/bin/ld: final > link failed: Bad value > clang-3.9: error: linker command failed with exit code 1 (use -v to see > invocation) > ni...

...e llvm suite of compilers to build shared libraries for talking to USB peripherals. The problem that I am having is that while I am able to build a shared library using llvm-gcc , the llvm-g++ compiler is giving me error messages saying " relocation R_X86_64_PC32 against undefined symbol `__morestack' can not be used when making a shared object; recompile with -fPIC Here's my configuration on my local machine: cat /etc/issue Ubuntu-12.04 uname -a Linux localhost 3.2.0-48-generic #74-Ubuntu SMP Thu Jun 6 19:43:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux dpkg -l | grep llvm ii lib...

On Tue, Sep 27, 2016 at 6:53 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > > On Sep 27, 2016, at 2:18 AM, Carsten Mattner <carstenmattner at gmail.com> > wrote: > > > >> On Mon, Sep 26, 2016 at 11:02 PM, Teresa Johnson <tejohnson at google.com> > wrote: > >> I'll either need to get a reproducer from you and/or try to repro

...ctly, you wanted to fold the red zone in the "do I need more stack" check, but I seed that you have a !EnableSegmentedStacks in the Red Zone check. Have you decided not to do it? *) You intend for the runtime to be compatible with the gcc one? Their stack allocating function is called __morestack... > [1] https://github.com/sanjoy/llvm/tree/segmented-stacks > Cheers, Rafael

...d CMAKE_C_COMPILER and CMAKE_CXX_COMPILER explicitly (you > might have had the right versions in your path?) I've exported CXX and CC to clang++ and clang, which happen to be the locally build 3.9 release branch versions (non-LTO variant). > I did an nm on the .so libraries to see where __morestack was > referenced and its linkage. No surprise, it is coming from > libLLVMRuntimeDyld.so, and I do see it as weak as expected: > > $ nm lib/libLLVMRuntimeDyld.so | grep morestack > w __morestack > > Can you do the above nm on your lib/libLLVMRuntimeDyld.so and...

On Tue, Sep 27, 2016 at 8:37 PM, Teresa Johnson <tejohnson at google.com> wrote: Just in case it's important, I'm using Arch Linux (and most Linux distros these days) CFLAGS/CPPFLAGS/LDFLAGS, which are as follows: $ grep FLAGS /etc/makepkg.conf CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"

Hi! I've attached my first week of work as a patchset for review. This is also available on Github [1]. By next Monday I intend to (more or less) finish up the preliminary parts concerning the codegen; and start working on the runtime (so that I can do a basic sanity check). [1] https://github.com/sanjoy/llvm/tree/segmented-stacks -- Sanjoy Das http://playingwithpointers.com

...rom a performance point of view. > > It is really not advised to use this. > > > I actually think Carsten was not getting BUILD_SHARED_LIBS=ON as I > had originally thought given the DSO error: His cmake command didn't > contain it, and from his email earlier this week, the __morestack > reference is coming from lib/liblldb.so, not an llvm library built > shared as I had assumed. Which also explains why he is still getting > it when configuring with -DBUILD_SHARED_LIBS=OFF. Correct. > I am having a bunch of trouble getting a release-built 3.9 compiler, > lots of...

On Mon, Sep 26, 2016 at 8:08 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: > On Mon, Sep 26, 2016 at 4:25 PM, Teresa Johnson <tejohnson at google.com> > wrote: > > No worries, thanks for the update. Teresa > > 2048 wasn't enough. Bumped to 4096. Only 1300 ninja targets left. > > Once I've been successful with this, I might try building a

On Mon, Oct 3, 2016 at 3:50 PM, Teresa Johnson <tejohnson at google.com> wrote: > > On Sun, Oct 2, 2016 at 4:02 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: >> >> On Sun, Oct 2, 2016 at 6:41 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > > I use trunk, but it depends on how close to the bleeding edge you > > > are

> On Sep 30, 2016, at 12:57 PM, Carsten Mattner <carstenmattner at gmail.com> wrote: > > On Fri, Sep 30, 2016 at 6:35 PM, Teresa Johnson <tejohnson at google.com> wrote: >> I just built a stage-1 compiler from the 3.9 release bits and built >> the lldb from head sources which worked fine. Let me try again using >> 3.9 build compiler to build 3.9 bits. >

...s.a lib/libclangEdit.a lib/libclangAST.a lib/libclangLex.a lib/libclangBasic.a lib/libLLVMMC.a lib/libLLVMBitReader.a lib/libLLVMCore.a lib/libLLVMSupport.a -lrt -ldl -lcurses -lpthread -lz -lm -Wl,-rpath,"\$ORIGIN/../lib" && : /usr/bin/ld.gold: bin/lldb-argdumper: hidden symbol `__morestack' in /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.2.1/libgcc.a(morestack.o) is referenced by DSO /usr/bin/ld.gold: final link failed: Bad value clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. -------------- next part...

Hi all! Now that LLVM has support for a larger attribute set, I think it is a good idea to add one that stops LLVM from generating segmented stacked version of a function. While implementing it, I ran into an issue: Currently, with segmented stacks enabled, LLVM sets the action for DYNAMIC_STACKALLOC to Custom, and lowers it into native X86 code. However, if a function has the nosegmentedstack

...1, %noreg, 1, %noreg, 40, %GS, %EFLAGS<imp-def> JA_1 <BB#0>, %EFLAGS<imp-use> Successors according to CFG: BB#3 BB#0 BB#3: Predecessors according to CFG: BB#4 %R10<def> = MOV64ri 40040 %R11<def> = MOV64ri 32 CALL64pcrel32 <es:__morestack>, %RSP<imp-use> MORESTACK_RET Successors according to CFG: BB#0 BB#0: derived from LLVM BB %0 Predecessors according to CFG: BB#3 BB#4 %EAX<def> = MOV32ri 40040; flags: FrameSetup %RDX<def> = MOV64rr %RAX; flags: FrameSetup %RCX<def&g...