search for: libgcc_eh

I get this when I type: brianherman at windows-8-[REDACTED] ~ $ nm libgcc_eh.a | grep register_frame nm: 'libgcc_eh.a': No such file brianherman at windows-8-[REDACTED] ~ $ nm libgcc_eh.a | grep register_fram nm: 'libgcc_eh.a': No such file brianherman at windows-8-[REDACTED] ~ $ On Tue, Jul 30, 2013 at 7:51 AM, Duncan Sands <baldrick at free.fr&gt...

brianherman at windows-8-doesn't rock /lib/gcc/i686-pc-cygwin/4.7.3 $ nm libgcc_eh.a | grep register_frame 000011b0 T ___deregister_frame 000011a0 T ___deregister_frame_info 000010d0 T ___deregister_frame_info_bases 00000fe0 T ___register_frame 00000fb0 T ___register_frame_info 00000f40 T ___register_frame_info_bases 00001070 T ___register_frame_info_table 00001010 T ___register_...

> $ nm libgcc_eh.a | grep register_frame > nm: 'libgcc_eh.a': No such file I think he meant to find out where libgcc_eh.a lives under Cygwin and execute the command on that file. It should be somewhere amongst the stuff installed with gcc, but the exact location can vary quite a bit. Cheers. Tim.

...vm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o):SectionMemoryManager.cpp:(.text+0x3b): > undefined reference to `__register_frame' I register_frame is used to enable the debugger (gdb) to debug JIT'd code. It is a function provided by libgcc, to be more precise in libgcc_eh. Is it in your copy? $ nm libgcc_eh.a | grep register_fram 0000000000001960 T __deregister_frame 0000000000001950 T __deregister_frame_info 0000000000001830 T __deregister_frame_info_bases 0000000000001750 T __register_frame 0000000000001740 T __register_frame_info 00000000000016b0 T __register_f...

.../stdio/vfprintf.c:(.text+0x28): undefined reference to `__aeabi_memset' /usr/local/arm-2009q3/lib/gcc/arm-none-linux-gnueabi/4.4.1//libgcc.a(_dvmd_lnx.o): In function `__aeabi_ldiv0': (.text+0x8): undefined reference to `raise' /usr/local/arm-2009q3/lib/gcc/arm-none-linux-gnueabi/4.4.1//libgcc_eh.a(unwind-arm.o): In function `unwind_phase2': unwind-arm.c:(.text+0xae4): undefined reference to `abort' /usr/local/arm-2009q3/lib/gcc/arm-none-linux-gnueabi/4.4.1//libgcc_eh.a(unwind-arm.o): In function `__gnu_Unwind_Resume': unwind-arm.c:(.text+0xbe8): undefined reference to `abort...

I got the following error while compiling llvm and clang under cygwin. /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o):SectionMemoryManager.cpp:(.text+0x3b): undefined reference to `__register_frame'

So, I remember we discussed this earlier this year, but I can't find the thread. The idea is to move libunwind into compiler-rt for the simple reasons below: 1. Unwinding is not exclusive to C++, nor exception handling. 2. Clang still includes libgcc_s and libgcc_eh when using compiler-rt (maybe eh isn't needed, but it was there for libgcc). 3. Testing the libunwind with libc++ on ARM is not possible, because libgcc_s merges RT abi with unwind, duplicating the implementation of some, but not all, unwind functions. I'm not sure how the move would take...

...known-linux-gnueabi \ --with-as=/home/kursh/arm/bin/arm-as \ --with-ld=/home/kursh/arm/bin/arm-ld \ --with-sysroot=/home/kursh/arms/sys-root \ --disable-libssp --disable-bootstrap --disable-werror make && make install build llvm-gcc break with error: rm -f ./libgcc_eh.a /home/kursh/arm/arm-unknown-linux-gnueabi/bin/ar rc ./libgcc_eh.a libgcc/./unwind-arm.o libgcc/./libunwind.o libgcc/./pr-support.o libgcc/./unwind-c.o /home/kursh/arm/arm-unknown-linux-gnueabi/bin/ranlib ./libgcc_eh.a /home/kursh/arm/bin/arm-ld: error: libgcc/./_udivsi3_s.o: unsupported reloc 40...

...sponse. Below is details ======== First I use $ clang++ test.cc `llvm-config --cxxflags --ldflags --libs` I works as usual. But if I use $ clang++ test.cc `llvm-config --cxxflags --ldflags --libs` -static It yells lots of undefined reference, like this /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libgcc_eh.a(unwind-dw2-fde-glibc.o): In function `__deregister_frame_info_bases': (.text+0x1a16): undefined reference to `pthread_mutex_unlock' /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libgcc_eh.a(unwind-dw2-fde-glibc.o): In function `__register_frame_info_bases': (.text+0x61): undefined reference to...

...vier users of libc++ can help you there. You still have to use LDFLAGS="--stdlib=libc++ -lc++abi -lunwind" and, if you're not installing it anywhere (but using the build directory), add LD_LIBRARY_PATH=build/lib to your environment. If you run into inconsistencies because libgcc_s / libgcc_eh are included, or if libstdc++ is included as well, you may have to use -nostdlibc++ to clean up the internal options, and then use --stdlib and friends to create a new set. It is confusing, but we don't want to make those libraries the default on any environment that might still need/use libst...

...ocation of the unwinder (libunwind). Currently, libunwind resides in a subdirectory of libc++abi. There seems to be some desire from multiple parties that it be moved into compiler-rt or a separate repository. Currently, when using compiler-rt as the runtime library (on Linux) we use libgcc_s and libgcc_eh as the builtins serve as the home for __gcc_personality_v0. This error handling personality requires unwinding support, which these libraries provide. This dependency can be fulfilled with libunwind. The concern that has been raised with adjusting this dependency has been that libunwind is not g...

...r/local/ssl/lib -L/usr/local/lib -L/usr/athena/lib -L/usr/afsws/lib -bloadmap -lssh -lopenbsd-compat -lkafs -ldes -lkrb -lz -lcrypto -ll ld: 0706-005 Cannot find or open file: libgcc.a ld:open(): A file or directory in the path name does not exist. ld: 0706-005 Cannot find or open file: libgcc_eh.a ld:open(): A file or directory in the path name does not exist. ld: 0706-005 Cannot find or open file: libgcc.a ld:open(): A file or directory in the path name does not exist. ld: 0706-005 Cannot find or open file: libgcc_eh.a ld:open(): A file or directory in the path...

...&5 /usr/ccs/bin/ld: skipping incompatible /work/net-local-b/sparc- sun-solaris2.9/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/sparcv9/libgcc.a when search ing for -lgcc /usr/ccs/bin/ld: skipping incompatible /work/net-local-b/sparc- sun-solaris2.9/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.2/sparcv9/libgcc_eh.a when sea rching for -lgcc_eh /usr/ccs/bin/ld: skipping incompatible /lib/sparcv9/libc.so when searching for -lc /usr/ccs/bin/ld: skipping incompatible /usr/lib/sparcv9/libc.so when searching for -lc /usr/ccs/bin/ld: skipping incompatible /usr/lib/sparcv9/libc.so when searching for -lc /usr/ccs/bi...

> > FWIW, I build baremetal newlib for arm-eabi using clang, and it works. I >> had to patch a few of the __attribute__((naked)) functions because they >> were using pre-UAL asm syntax, but for the most part it "just works". >> > I build the baremetal newlib using arm-none-eabi-gcc as well, but after linking with the hello world program, it failed to run on

...bc++ or libstdc++ the resulting compiler can use both after the fact As Renato described above in more detail LDFLAGS="--stdlib=libc++ -lc++abi -lunwind" would be used to tell that resulting compiler to link its programs with libc++, libc++abi and libunwind Rather than using libstdc++ and libgcc_eh If you want to know how to change the default to do this without touching the LDFLAGS for your target this you must look in the clang repo under lib/driver If you have any trouble doing this I'd be glad to help you change the default behavior if let me know what your target is. Kind Regards M...

Hi, I am wondering about the meaning of the cmake flags LLVM_ENABLE_LIBCXX and LLVM_ENABLE_LIBCXXABI. Are they used to indicate that if the C/C++ compiler for building LLVM is clang, and if this clang has support for libc++ with libc++Abi, that both lib++ and libc++abi should be used (instead of linking to the default, which at least on Linux is libstdc++)? If not, what is the canonical way of

...cussed this earlier this year, but I can't find the > thread. > > > > The idea is to move libunwind into compiler-rt for the simple reasons > below: > > > > 1. Unwinding is not exclusive to C++, nor exception handling. > > 2. Clang still includes libgcc_s and libgcc_eh when using compiler-rt > > (maybe eh isn't needed, but it was there for libgcc). > > 3. Testing the libunwind with libc++ on ARM is not possible, because > > libgcc_s merges RT abi with unwind, duplicating the implementation of > > some, but not all, unwind functions. &g...

...nathan Roelofs <jonathan at codesourcery.com> wrote: > I think this dependence should be satisfied by the target system's unwinder, > whatever that is. If folks want to use this libunwind for their platform, > that's fine... but we should probably continue to use libgcc_s and libgcc_eh > on linux when that's the platform's unwinder. That's precisely the point. People should use unwinders they want, and libc++abi should be completely agnostic of which one you use. > +1 for putting it in a separate repo. Separate repos helps keep layering > nonsense to a min...

...>  ../configure  --target=arm-unknown-linux-gnueabi --program-prefix=arm- > --prefix=/home/kursh/arm --enable-gold --enable-plugins > --with-sysroot=/home/kursh/arms/sys-root It seems you've configured binutils with gold... > /home/kursh/arm/arm-unknown-linux-gnueabi/bin/ranlib ./libgcc_eh.a > /home/kursh/arm/bin/arm-ld: error: libgcc/./_udivsi3_s.o: unsupported reloc > 40 against local symbol But gold for ARM is known to be incomplete/broken/WIP -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...codesourcery.com> > wrote: > > I think this dependence should be satisfied by the target system's > unwinder, > > whatever that is. If folks want to use this libunwind for their platform, > > that's fine... but we should probably continue to use libgcc_s and > libgcc_eh > > on linux when that's the platform's unwinder. > > That's precisely the point. People should use unwinders they want, and > libc++abi should be completely agnostic of which one you use. The library is agnostic of the unwinder, the driver is who cares (as it needs to...