similar to: [LLVMdev] JITMemoryManager

Hi Frank, The project really needs to be looking to move away from the old JIT and to MCJIT. LLVM is actively working to kill the old JIT. It’s already unmaintained. MCJIT is the way forward. Can you elaborate on what’s blocking its adoption for Mesa? -Jim On Oct 1, 2013, at 10:44 AM, Frank Henigman <fjhenigman at google.com> wrote: > Mesa (http://www.mesa3d.org/) uses LLVM to compile

I'll try to find out, or get someone to explain, why Mesa selects MCJIT with LLVM 3.1 only and JIT for other LLVM versions. I'm not keen to code a fourth attempt (1: copy JIT code, 2: delegating manger, 3: derive from DefaultJITMemoryManager, 4: copy MCJIT code) but I'll try copying code with MCJIT. Is that the usual route for people who want to delete all LLVM engines, etc. while

Hi Lang, Yeah, I remember this case. Basically what’s happening is that there are relocations for ELF on x86 that use a value that is present in the object image as part of the calculation for the final value that goes in the same location. If you ever find yourself applying relocations for a second time (for instance, because the loaded object location is remapped for out-of-proc execution)

Chris asked me to write up "LLVM Developer's Guide to Dwarf Support" for LLVM maintainers. We are still in early stages, but we thought we'd get it out there for the "need to bleeders." At some point this information will be formalized and added to the LLVM documentation. The enclosed document gives specific instructions for adding source line number support

Hi! The LLVM Bytecode File Format specifies an optional SectionID attribute for globals. I didn't find a matching attribute in the LLVM source code. Code such as: int a __attribute__ ((section ("A_SECTION"))); compiles with llvm-gcc, but apparently the section information is stripped (the object file doesn't contain "A_SECTION"). Is the SectionID feature

Hi, Thanks for your ideas. Memory allocation already exceeds 2x64K in the "working" case so it's not the condition of allocating more than 64K. To be sure I had modified SectionMemoryManager::allocateSection to allocate four time the required memory but it did not trigger more crashes.I debugged through the allocation code including the Win32 code and it seems to work well. I have

YES, this is the problem! The program work ok, even a 5x larger version works well. Clearly the _chkstk calls must be emitted with ELF target on Windows as well - why not? I'd like to make a patch and fix this right. I experimented with both changes and practically only the lib/Target/X86/X86ISelLowering.cpp fixes the problem. The other change lib/Target/X86/X86FrameLowering.cpp was not

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

So it looks like 0x0A3600D1 is a good code address and there's no problem executing the code there, but 0x00BC7680 is a bad data address. Is that correct? If so, this is almost certainly a relocation problem. You just need to find a relocation that writes an entry (probably a relative offset) at 0x0A3600D1+the size of the instruction at that address. BTW, what I said before about not being

Hi all, I am new to LLVM and have been working through the Kaleidoscope tutorial. Everything is working fine so far except for local externs (as opposed to things like the math functions, which are working). Note that I have seen this bug with the reference code listing, as well as my own code. link to code: https://llvm.org/docs/tutorial/LangImpl05.html#full-code-listing [c34n10 kaleidoscope]

If it's a Windows-only thing the correct tests would be: if (NumBytes >= 4096 && STI.isOSWindows()) { and if (Subtarget->isTargetWindows()) where bool isOSWindows() const { return TargetTriple.isOSWindows(); } Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Glad that helped! As I understand it __chkstk is always required on > Windows

I would guess that it's crashing somewhere in the generated code. On Windows we don't have a way to get call stacks to the generated code (though if you want to try it on Linux, that should work). You can probably look at the address where the crash is occurring and verify that it is in the generated code. There are a couple of things I would look for. First, I'd take a look at the

Hi Yaron, If you're outputting ELF on Windows this 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

Helo List, Sorry I missed the rest of my email in my previous post. Please see below. I'm having an issue using the AND (&) operator evaluation in the code of my dialplan. The dial plan is coded to detect inbound DTMF digits from callers. key "1" is equivalent to "yes" and key "2" is equivalent to "no" in two diferent contexts in the dial plan.

On 09/02/15 17:44, Emil Velikov wrote: > Hi Sedat, > > On 07/02/15 22:42, Sedat Dilek wrote: >> [ Please CC me I am not subscribed to mesa-dev and llvmdev MLs ] >> >> Hi, >> >> I already reported this when playing 1st time with my llvm-toolchain >> v3.6.0rc2 and mesa v10.3.7 [1]. >> The issue still remains in mesa v10.4.4. >> >> So,

OS is Windows 7 64 bit OS, compiler is 32 bit Visual C++ 2012 with 32 bit. The target which is i686-pc-mingw32-elf so I can use the ELF dynamic loader. Code model, relocation model and and memory manager are whatever default for this - did not modify. The Module comes from clang. The source is 1000 or more lines repeating C++ code in one big function: A+1; A*B.t(); where A and B are

Glad that helped! As I understand it __chkstk is always required on Windows regardless of output type, I had meant to file a bug about this but had apparently forgotten to do so. I think the check needs to be that the target is Windows and ignore the output type, Linux and OSX don't use this. Cheers, Andrew On Wed, Oct 23, 2013 at 11:32 AM, Yaron Keren <yaron.keren at gmail.com>

[ Please CC me I am not subscribed to mesa-dev and llvmdev MLs ] Hi, I already reported this when playing 1st time with my llvm-toolchain v3.6.0rc2 and mesa v10.3.7 [1]. The issue still remains in mesa v10.4.4. So, this is a field test to see if LLVM/Clang v3.6.0rc2 fits my needs. I see the following build-error... ... make[4]: Entering directory

Hi! I am using wine to compile code for Texas Instruments dsp's. One step in the process is generating code from a graphic configuration file (tcf). When I try to do that, it fails with some Java related messages. The -b in my command tells tconf.exe to run in batch mode, so it doesn't try to open a GUI or something like that. I ran the same command in a dos-shell and it worked

This is the right fix if Cygwin wants calls to __chkstk. Otherwise you'll want TargetTriple.isOSMSVCRT(). On Wed, Oct 23, 2013 at 2:50 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > If it's a Windows-only thing the correct tests would be: > > if (NumBytes >= 4096 && STI.isOSWindows()) { > > and > > if (Subtarget->isTargetWindows()) >