similar to: [LLVMdev] LLVMdev Digest, Vol 112, Issue 59

I don't think we should attempt to mangle symbols declared in assembly source files. If you're writing assembly, you will need to handle ABI portability, including the _ prefix on win32 x86. clang will run the C preprocessor for you if you use the .S file suffix (case matters). On Tue, Oct 22, 2013 at 7:08 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com>wrote: > For example, I

2013/10/23 Reid Kleckner <rnk at google.com> > I don't think we should attempt to mangle symbols declared in assembly > source files. If you're writing assembly, you will need to handle ABI > Sorry for the unclear statements, I didn't means the assembler to mangle symbols declared in assembly source files, I means directly use assembly directive to choice which symbol

For example, I execute the following command sequences: H:\CI\bld\compilers\musl\src\math\i386>type sqrt.s #.globl _sqrt .global sqrt #.type sqrt, at function #_sqrt: sqrt: fldl 4(%esp) fsqrt fstsw %ax sub $12,%esp fld %st(0) fstpt (%esp) mov (%esp),%ecx and $0x7ff,%ecx cmp $0x400,%ecx jnz 1f and $0x200,%eax

Hi, I am writing my own passes in LLVM. I start with a function with various uses of a LLVM IR function parameter: e.g. paramB. After running one of my passes, all the uses of the paramB vanish. How do I do the last step, and remove the paramB from the function parameters in the LLVM IR? I want to go from: function test( int paramA, int paramB) { ... } to: function test( int paramA) { ... }

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

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>

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

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 Jim, Clearly searching for name should not be linear in modules but with a map of some kind. After compilation to IR each module has a StringMap symbol table. After compiling to MC and loading the object file, the dynamic linker has a StringMap symbol table for all loaded modules. In the usual use case you'll load module(s) into MCJIT and then compile / link them and all is well, no

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

There's probably a lot that we could do, but I can't think of anything easy. Basically every time we need to look up a symbol by name we're going to each module and saying "Do you have this symbol?" It would likely be much better if we grabbed the function names from the module and did the search ourselves so that we could keep some information about the things that

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

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, you are correct Yaron. Before we commit this we ought to put a check in to see what the target OS is. I just suggested the change below as a quick and easy way to verify that this was the cause of the problem. I'll clean it up. -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Monday, October 14, 2013 9:09 PM To: Christian Schafmeister; Kaylor, Andrew; iain at

Hi Andy, I added the runStaticConstructorsDestructors and FindFunctionNamed functions. This also required making them virtual in EE.h. I'm not sure about FindFunctionNamed: In addition to searching finalized modules, should it search Added and Loaded modules? If it finds a Function in these, should it compile and finalize it before returning the Function* ? I modified the implementation

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

I should have read this before sending my previous reply. :-) I'm not a big fan of default parameters, but some form of what you are suggesting may be useful. See my other comments on this topic in the other reply. -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Saturday, October 19, 2013 3:17 PM To: Kaylor, Andrew; <llvmdev at cs.uiuc.edu> Subject: An enhancement

I'm not aware of such a limitation. What architecture, code model and relocation model are you using? Are you using the SectionMemoryManager? -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Tuesday, October 22, 2013 8:12 AM To: <llvmdev at cs.uiuc.edu>; Kaylor, Andrew Subject: Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen? I'm running in MCJIT a

If I spoke incorrectly about what systems this problem/change effects I apologize. I'll leave it to Andrew to determine that. Best, .Chris. "Kaylor, Andrew" <andrew.kaylor at intel.com> writes: > Yes, you are correct Yaron.  Before we commit this we ought to put a > check in to see what the target OS is.  I just suggested the change > below as a quick and easy way