similar to: [LLVMdev] Typo in IsLegalToCallImmediateAddr?

On 2011-07-01 17:13, David Meyer wrote: > It seems that the || should be && here? > > /// IsLegalToCallImmediateAddr - Return true if the subtarget allows calls > /// to immediate address. > bool X86Subtarget::IsLegalToCallImmediateAddr(const TargetMachine &TM) const { > if (Is64Bit) > return false; > return isTargetELF() || TM.getRelocationModel() ==

Rafael, I believe your example is not related to IsLegalToCallImmediateAddr. This is an example of calling to an immediate address: typedef int (*funcptr)(void); int main() { funcptr foo = (funcptr)0x100; foo(); } If IsLegalToCallImmedateAddr is true, this generates a call to absolute address 0x100: call 0x100 This requires a relocation of the value 0x100 - PC. (NOTE: this is NOT the

2011/10/17 David Meyer <pdox at google.com>: > Rafael, > > I believe your example is not related to IsLegalToCallImmediateAddr. > > This is an example of calling to an immediate address: > > typedef int (*funcptr)(void); > > int main() { >  funcptr foo = (funcptr)0x100; >  foo(); > } > > If IsLegalToCallImmedateAddr is true, this generates a call to

The current rule is: /// IsLegalToCallImmediateAddr - Return true if the subtarget allows calls /// to immediate address. bool X86Subtarget::IsLegalToCallImmediateAddr(const TargetMachine &TM) const { if (In64BitMode) return false; return isTargetELF() || TM.getRelocationModel() == Reloc::Static; } But this is not doing the correct thing for ELF PIC. The straight-forward way to fix

Rafael, I believe MachO can't represent this relocation, even in non-PIC mode. On my Mac, I tried compiling "call 256". I got: in section __TEXT,__text reloc 0: R_ABS reloc but no absolute symbol at target address I believe the correct thing to do is: isTargetELF() && TM.getRelocationModel() == Reloc::Static This will do the right thing on ELF, and the right thing on

2011/10/21 David Meyer <pdox at google.com>> Rafael, > > I believe MachO can't represent this relocation, even in non-PIC mode. > On my Mac, I tried compiling "call 256". I got: I think PIC is just the default (the kernel being non-PIC for example), but I am not sure. > in section __TEXT,__text reloc 0: R_ABS reloc but no absolute symbol > at target address

Rafael, Use this bitcode: define i32 @main() nounwind { entry: %call = tail call i32 inttoptr (i64 256 to i32 ()*)() nounwind ret i32 0 } And this command: $ llc -mtriple "i686-linux-gnu" test.ll -o test.s -filetype=asm -relocation-model=pic - pdox

> And this command: > > $ llc -mtriple "i686-linux-gnu" test.ll -o test.s -filetype=asm > -relocation-model=pic I can reproduce it now. Sorry, I was using a test returning void and we don't have tail call of immediate. My impression in that the right fix would be to just remove the "isTargetELF()". It would make the function correct for ELF and not less

> Could be, echristo, bigcheese, would this be correct for Mach-O and COFF? bigcheese noted on IRC that the test crashes the COFF emitter. For some reason I am always getting movl $256, %eax ## imm = 0x100 calll *%eax on darwin already, so I guess you are right, the correct would be isTargetELF() && TM.getRelocationModel() == Reloc::Static; Please include a test

IIRC the kernel uses relocation model as static. -eric On Oct 21, 2011, at 3:57 PM, David Meyer wrote: > Eli, > > Hm. There's a test in (CodeGen/X86/call-imm.ll) which uses darwin with > relocation model static. It expects to use call-to-immediate. > > Is this in error? Should I disable this check? > > - pdox > > On Fri, Oct 21, 2011 at 11:49 AM, Eli

2011/10/21 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>: >> Could be, echristo, bigcheese, would this be correct for Mach-O and COFF? > > bigcheese noted on IRC that the test crashes the COFF emitter. For some > reason I am always getting > >        movl    $256, %eax              ## imm = 0x100 >        calll   *%eax > > on darwin already IIRC, we

Thought a bit more. There's also -mdynamic-no-pic. Not typically used these days, but is still there AFAIK. -Jim On Oct 21, 2011, at 4:05 PM, Eric Christopher wrote: > IIRC the kernel uses relocation model as static. > > -eric > > On Oct 21, 2011, at 3:57 PM, David Meyer wrote: > >> Eli, >> >> Hm. There's a test in (CodeGen/X86/call-imm.ll) which

Eli, Hm. There's a test in (CodeGen/X86/call-imm.ll) which uses darwin with relocation model static. It expects to use call-to-immediate. Is this in error? Should I disable this check? - pdox On Fri, Oct 21, 2011 at 11:49 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > 2011/10/21 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>: >>> Could be,

Hi Evan, Thanks for the pointers. We found a simple test case that causes the problem (thanks to Tom in my group): #include<stdio.h> #include<stdlib.h> void test(); void (*funcPtr)(); int main(int argc, char **argv) { funcPtr = test; test(); } void test() { if(funcPtr == test) { printf("OK!\n"); } else { fprintf(stderr, "Bad!\n"); exit(1);

Hello, I am currently facing an issue at linking stage when compiling basic C code for an embedded PPC32 platform and linking with LLD. For external symbol linkage LLVM appears to use PLT which results in generating a R_PPC_PLTREL24 relocation, that is not support by LDD. Therefore even such a basic example cannot be built: /* s.c */ int f() { return 0; } /* t.c */ int f(); int _start() {

I have a function in R that takes another function as argument: f <- function(g, ...) { #g is expected to be a function } I want to see if there is a way to implement "f" in C and calling it from R using ".C" interface. I know that I can use function pointers for my C implementation, but I imagine it's going to be nearly impossible to pass a function from R to C. Are

Hal, I very well understand that LDD may not be in a good state for PPC32, and it would definitely need some improvements sooner or later. In fact I even submitted a patch adding a relocation to ldd just a few hours ago. However, this particular case is not related to LDD, it is a design issue and furthermore a regression in LLVM itself. I checked gcc, and neither does it try to use PLT and

I've filed PR3043 for this. Evan On Nov 3, 2008, at 4:00 PM, Prakash Prabhu wrote: > Hi Evan, > > Thanks for the pointers. We found a simple test case that causes the > problem (thanks to Tom in my group): > > #include<stdio.h> > #include<stdlib.h> > > void test(); > void (*funcPtr)(); > > int main(int argc, char **argv) { > funcPtr =

Hi Prakash, Unfortunately it looks like you need to do quite a bit of investigation into this. However, I hope I can provide some useful tips. 1. In general, lli and llc generate exact the same code except lli default to static codegen while llc defaults to dynamic-no-pic codegen. So try passing -relocation-model=dynamic-no-pic to lli. If this works, that means there are issues with

I'm rebuilding the centosplus kernel with ISA P&P and ISA some devies enabled. At the very end of compilation, I got a lot of error messages that looked like: Error: ./init/initramfs.o .text refers to 0000046e R_386_PC32 .init.text Error: ./init/initramfs.o .text refers to 0000059c R_386_PC32 .init.text Error: ./init/initramfs.o .text refers to 000007a8 R_386_PC32