search for: istargetcoff

...oth changes and practically only the lib/Target/X86/X86ISelLowering.cpp fixes the problem. The other change lib/Target/X86/X86FrameLowering.cpp was not required to fix the problem thus it is probably required for other reasons. So, should I patch both tests? Is the correct patch removing the test isTargetCOFF() completely? Or enabling it for both COFF or ELF tarrgets? I mean - is there any X86 target that does NOT require this stack checking? Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Hi Yaron, > > If you're outputting ELF on Windows this sounds like an issue...

...nly the > lib/Target/X86/X86ISelLowering.cpp fixes the problem. The other change > lib/Target/X86/X86FrameLowering.cpp was not required to fix the problem > thus it is probably required for other reasons. > > So, should I patch both tests? > Is the correct patch removing the test isTargetCOFF() completely? > Or enabling it for both COFF or ELF tarrgets? > I mean - is there any X86 target that does NOT require this stack checking? > > Yaron > > > > 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > >> Hi Yaron, >> >> If you're...

...nly the > lib/Target/X86/X86ISelLowering.cpp fixes the problem. The other change > lib/Target/X86/X86FrameLowering.cpp was not required to fix the problem > thus it is probably required for other reasons. > > So, should I patch both tests? > Is the correct patch removing the test isTargetCOFF() completely? > Or enabling it for both COFF or ELF tarrgets? > I mean - is there any X86 target that does NOT require this stack checking? > > Yaron > > > > 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > >> Hi Yaron, >> >> If you're...

...get/X86/X86ISelLowering.cpp fixes the problem. The other change >> lib/Target/X86/X86FrameLowering.cpp was not required to fix the problem >> thus it is probably required for other reasons. >> >> So, should I patch both tests? >> Is the correct patch removing the test isTargetCOFF() completely? >> Or enabling it for both COFF or ELF tarrgets? >> I mean - is there any X86 target that does NOT require this stack >> checking? >> >> Yaron >> >> >> >> 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> >> >&...

...is sounds like an issue we ran into where __chkstk calls weren't being output in the assembly due to an explicit check for COFF output. Once stack allocations in a given function exceeded some amount we'd get exactly this kind of crash in the function initialization. If you take a look for isTargetCOFF() in lib/Target/X86/X86ISelLowering.cpp and lib/Target/X86/X86FrameLowering.cpp you should be able to remove that check to force __chkstk output to see if that helps. Cheers, Andrew On Wed, Oct 23, 2013 at 1:22 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > Yes, this is correct co...

Yes, this is correct code address accessing bad data address. However, there is no other relocation before .text or near it. I'll send you the full debug printout, maybe you'll note something. The problem could be result of something else entirely else than the linker such as some library initialization code that by chance worked with smaller code but fails now. I need to debug and see

It's not a solution to the actual bug (which is, as the thread you linked discusses, a problem with the assumption on LLVM's part that the __chkstk function lies within 2GB of the emitted code's address space) but there is a simple workaround: hoist all allocas to the first basic block of your function. This allows the JIT to perform all stack allocations in a single adjustment of the

Hi, I'm using LLVM to convert expressions to native assembly, the problem is when LLVM compiles this code: define void @fn_0000000000000000(i8*, i8*, i8*) { bb: %res = alloca i32 %3 = load i32* %res %4 = bitcast i8* %0 to i32* %5 = load i32* %4 %6 = bitcast i8* %0 to i32* %7 = load i32* %6 %8 = xor i32 %5, %7 store volatile i32 %8, i32* %res %9 = load i32* %res %10 = icmp