similar to: What is __builtin_dwarf_cfa()?

Hi all, Here's a potential patch for LLVM-GCC: Index: llvm-convert.cpp =================================================================== --- llvm-convert.cpp (revision 41260) +++ llvm-convert.cpp (working copy) @@ -4240,11 +4240,12 @@ return false; int cfa_offset = ARG_POINTER_CFA_OFFSET(0); - - Result = Builder.CreateCall(Intrinsic::getDeclaration(TheModule, -

Firstly, apologies if this is not the right place to be asking this question--feel free to point me in the correct direction. I could be doing something wrong here but stackoverflow didn't feel like the correct place for this since there's so little there about LLVM ORC. Basically, I have a reproduction case (below) where if I throw an exception before I call JITSymbol::getAddress()

On 8/29/07, Bill Wendling <isanbard at gmail.com> wrote: > On 8/29/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > > Hello, Bill > > > > > It may be my lack of understanding, but it appears that having -- > > > enable-eh set during compilation of llvm-gcc is causing extra files > > > to be compiled. > > Oh, no. They are always

Hi David, Sorry to hear. Has anyone followed up with you yet? I've continued to dig in to this in my spare time and I've found the issue. It's a use-after-free, rather than any sort of memory smashing. ORC is currently failing to deregister the EH-frame section when the JIT is torn down (but *is* deallocating the memory for it). Normally that's not disastrous (though it does

Hi David, This looks like bad eh-frame data due to a failure to fix up the frame descriptor entries: <debug: adding frame> EHFrameAddr: 0x7feae5827000, EHFrameLoadAddr: 0x00000000e5827000, EHFrameSize: 60 ==64588==ERROR: AddressSanitizer: SEGV on unknown address 0x7feae5827020 (pc 0x7feae886d970 bp 0x000000000001 sp 0x7ffca10e75f8 T0) Eyeballing the code in RuntimeDyldELF (vs

Bill, > The reason for it: when going to calculate the CFA in LLVM, the > original code was adding an offset of type i32 to a pointer. This is > fine if pointers are 32-bits, but we get an assert if the types are > different. By converting the cfa_offset to a pointer, we get it to be > that size. Please ignore my prev. e-mail. The code breaks at least 32-bit stuff. The arg of

Hi David, Thanks very much for that. I'll continue to dig in as time permits, and I'll update the bug report with my progress once it's filed. Cheers, Lang. On Mon, Apr 17, 2017 at 6:42 PM, David Lurton <dlurton at gmail.com> wrote: > Thanks Lang. I think I'll go the bug creation route. I have an email out > to llvm-admin requesting an account on bugs.llvm.org.

Bill, > The built-in dwarf_cfa doesn't take an argument. It returns a pointer. Ah. Sorry for confusion: gcc's __builtin_draft_cfa doesn't have any argument LLVM's eh_dwarf_cfa intrinsic has extra "offset" argument, which is i32, because we have to propagate some information from GCC to LLVM. > But there's an offset associated with the CFA. So it looks like

I can't boostrap LLVM CFE at FreeBSD with current LLVM and LLVM CFE CVS sources. GCC bootstrap terminated with error: /usr/home/wanderer/pkg/build/llvm/objcfe/gcc/xgcc -B/usr/home/wanderer/pkg/build/llvm/objcfe/gcc/ -B/home/wanderer/pkg/build /llvm/night/cfe/i386-unknown-freebsd5.3/bin/ -B/home/wanderer/pkg/build/llvm/night/cfe/i386-unknown-freebsd5.3/lib/ -isystem

2018-01-24 0:23 GMT+08:00 Ben Craig <ben.craig at ni.com>: > The high level of what happens is that __builtin_eh_return forces a spill > of all the non-volatile registers. The unwinder then has a starting point > for populating and adjusting those non-volatile registers. > > > > This approach usually requires that the function calling > __builtin_eh_return be built

Hi everyone, -r136747 of llvm-gcc (and possibly others) is apparently tickling a binutils issue on linux x86-64 Has anyone seen anything like this? Thanks -jason -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110806/e7e717ef/attachment.html> -------------- next part --------------

At the last step of building llvm for arm target, I am unable to build llvm-gcc. I am trying the follwing options:   $ ../llvm-gcc/configure --target=arm-linux --enable-pic --program-prefix=llvm- --prefix=/llvm/install --disable-multilib --disable-optimized --enable-bindings =none --enable-llvm=$PWD/../llvm-2.8 --enable-languages=c,c++ --disable-bootstr ap   Then I get the following error when I

Dear Anton, Thank you again for your help! I tried with the following options (adding --with-cpu=arm7tdmi and using binutils from cvs snapshot): ../llvm-gcc4.2-2.6.source/configure --prefix=/usr/local/cross-llvm-gcc-arm-elf-4.2-2.6 --program-prefix=llvm- --enable-llvm=/Users/dummy/Develop/llvm/llvm-build --enable-languages=c,c++ --host=i686-apple-darwin9 --build=i686-apple-darwin9

While attempting to compile llvm-gcc on Intel x86_64 2-way 4-core machine, i got the following errors: configure line i used is: ../llvm-gcc4.2-2.5.source/configure --enable-llvm=`pwd`/../../llvm-2.5 --program-prefix=llvm- --enable-languages=c,c++ --host=x86_64-redhat-linux --build=x86_64-redhat-linux --disable-multilib --disable-shared Errors: lvm-gcc4.2-2.5.source/gcc/.

Hi, I'm trying to build llvm-gcc-4.2 on Ubuntu 11.04 (the Natty Narwhal). The "make" fails here, trying to build libgcc: /home/jay/llvm/gitobjdir-gcc/./gcc/xgcc -B/home/jay/llvm/gitobjdir-gcc/./gcc/ -B/home/jay/llvm/local/x86_64-unknown-linux-gnu/bin/ -B/home/jay/llvm/local/x86_64-unknown-linux-gnu/lib/ -isystem /home/jay/llvm/local/x86_64-unknown-linux-gnu/include -isystem

On Dec 7, 2007, at 4:40 PM, Dale Johannesen wrote: > So I couldn't get exceptions to work on PPC darwin. After much > digging and confusion, there seem > to be two separate issues. Ok. > The gcc testsuite is running the version of the unwinding code that > was built with the local (llvm-)gcc, > which doesn't work because nobody has implemented >

On Aug 28, 2007, at 11:35 PM, Chris Lattner wrote: > On Aug 28, 2007, at 11:20 PM, Duncan Sands wrote: > >>> This is a (very) rough patch to fix building LLVM with exceptions on >>> PPC Darwin. Basically, it puts the burden of adding the "--enable- >>> eh" >>> on the specific target, which is where I think it should go. >> >> I

On 8/29/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > Hello, Bill > > > It may be my lack of understanding, but it appears that having -- > > enable-eh set during compilation of llvm-gcc is causing extra files > > to be compiled. > Oh, no. They are always compiled. > > > They do. However, it doesn't seem to stop it from failing during > >

Hi there I'm new to LLVM & am trying to build llvm-gcc. I'm using Ubuntu 10.0.4. on an AMD64 processor. I've had no problems with building the LLVM suite itself, but during llvm-gcc compilation I am presented with the following error message - does anybody happen to know if there is any remedy? /root/llvm_gcc_source/llvm-gcc-objects/./gcc/xgcc

Anton, I went with the first alternative with some success. However, now I get some errors during the build of libgcc with 'multiply defined symbols'. One thing I noticed is the following fact: Definition in unwind-pe.h: static const unsigned char * read_sleb128 (const unsigned char *p, _Unwind_Sword *val) --- GCC 4.2.4 bootstrapped on Solaris/SPARC -bash-3.00$ nm unwind-dw2.o | grep