similar to: [LLVMdev] Problem with LLVM CFE bootstrap at FreeBSD

Chris Lattner wrote: > On Thu, 2 Mar 2006, Vladimir Prus wrote: >>>> The instructions seem to have one path wrong. It says to get: >>> >>> I'll put together a tarball today. That will be easier than dealing >>> with a patch, and it will include a bunch of bugfixes since the previous >>> email. >> Further into process, I get this error:

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()

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

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.

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

[My very deepest apologies in advance if this is not plain text; I am recently at a new job in a windows-based environment and have not yet set up my favorite old (pine) system. I have tried my best to strip all formatting from the message..] I'm overlaying plots of tree locations mapped before and after logging activities and checking my matched individuals using several arguments to

Command from LLVM CFE bootstrap sequence at FreeBSD: gmake -C runtime install-bytecode terminated with error (verbose mode): --8X------------------------------------------------------- llvm[2]: Installing Debug Bytecode Archive /usr/home/wanderer/pkg/build/llvm/night/cfe/bin/../lib/libcrtend.a /usr/bin/install -c -D /usr/home/wanderer/pkg/build/llvm/obj/Debug/lib/libcrtend.bca

On Apr 19, 2007, at 2:37 PM, David Greene wrote: > Got a strange problem. With our modified llvm here,llvm-gcc won't > bootstrap. It fails compiling unwind-dw2.c during translation from > the gcc IR to llvm. It fails with -O0 -emit-llvm so according to > the docs, this is strictly a frontend bug. A run of delta produced > an 18 line testcase with nothing remarkable in it.

On Thu, 2 Mar 2006, Vladimir Prus wrote: >>> The instructions seem to have one path wrong. It says to get: >> >> I'll put together a tarball today. That will be easier than dealing with >> a patch, and it will include a bunch of bugfixes since the previous email. > Further into process, I get this error: > In file included from

Got a strange problem. With our modified llvm here,llvm-gcc won't bootstrap. It fails compiling unwind-dw2.c during translation from the gcc IR to llvm. It fails with -O0 -emit-llvm so according to the docs, this is strictly a frontend bug. A run of delta produced an 18 line testcase with nothing remarkable in it. However, it bootstraps fine using the official llvm sources. Note that the

>> I'm not sure that I follow. The qmtest stuff isn't working on Zion >> because (I believe) of an upgrade that happened on the machine (the >> qmtest >> binary doesn't work anymore?). Are you seeing a problem on freebsd where >> the feature tests go into a loop? If so, can you provide us with more >> information? >> make, ~ > ps -xu

I think there is a very similar situation with the PowerPC/Mac OS X nightly tests. Over each of the past few nights, something has been filling up the process table, causing me to be unable to log in. The nightly tester wrote out regression test and feature test logs featuring hundreds of "Resource temporarily unavailable" errors from fork(), so I assume it's the qmtest

For VC++, I solved this by having bison/flex put the files into the obj directories. I also have it unconditionally regenerate the files if bison/flex is available, and copy them from src if they are not. Chris Lattner wrote: > On Wed, 11 Jan 2006, Vladimir A. Merzliakov wrote: > >> I can't build LLVM CFE after this patchs >>

A typo in test/Makefile was the trigger for this problem: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/ 020216.html John, can you please look into this bug some more and add some error checking to the llvm-specific qmtest python modules to make this error less severe? Thanks! -Brian On Nov 3, 2004, at 10:35 AM, Brian Gaeke wrote: > > I think there is a very

No solutions come to mind. Conflicts are conflicts and must be resolved manually. This situation should only occur if you change the .l/.y file and then update the .h/.cpp files after someone else has changed the .l/.y file and regenerated the .h and .cpp. That doesn't seem like a high frequency scenario that we need to worry about. Not sure there's much we could do even if it was. Reid.

I attempt install and use qmtest for run LLVM testsuit at FreeBSD, but without success. I have installed qm-2.2 (latest and single version accessable from http://www.codesourcery.com/qmtest/download.html in sources) When I start qmtest for LLVM ("make qmtest" in <llvm-obj-dir>/test directory - right?) error printed: ---8X---------------

On Wed, 11 Jan 2006, Vladimir A. Merzliakov wrote: > I can't build LLVM CFE after this patchs > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060109/030639.html > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060109/030654.html This is most likely because you have conflict markers in the generated files in the lib/AsmParser directory. Try removing

I resend email with updated (after mass header move) log examples. > LLVM build without big problems in obj dir == src dir case (for example, > last night tester build) > But I have problem with building CVS version LLVM in obj dir != src dir > case. > gmake[1]: Entering directory `/usr/home/wanderer/pkg/build/llvm/obj/projects' gmake[2]: Entering directory

Brian Gaeke wrote: > > A typo in test/Makefile was the trigger for this problem: > > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/ > 020216.html > > John, can you please look into this bug some more and add some error > checking to the llvm-specific qmtest python modules to make this error > less severe? Does the fork bomb occur in the

I can't build LLVM CFE after this patchs http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060109/030639.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060109/030654.html Build terminated with messages: --8X---------------------------------------------- llvm[2]: Compiling Lexer.cpp for Debug build In file included from