similar to: [LLVMdev] LTO & PIC

On Jun 16, 2009, at 1:17 PMPDT, Anton Korobeynikov wrote: > Hello, Aaron > >> Can I ask what platform ABI's are documented other than Itanium ? > I'd bet all platform ABI are more or less documented. > >> I need to get to understand PIC on x86, x86_64 and PowerPC for the >> COFF and MachO backends. > ABI is normally induced by platform, not by

Aaron, > Maybe we should collect references and do some LLVM PIC documentation and > put it on LLVM website ? What you mean as "LLVM PIC documentation"? What should be included there? > Okay. We need documentation, what is the difference between DynamicNoPIC and > full PIC ? >From TargetMachine.cpp (actually this is show in llc --help): cl::values(

I was having problems with my exception handling due to mixing PIC and non-PIC code into my executable. Now I'm confused as to how I'm supposed to do this correctly when I do have to mix different code types. The basic setup: - shared library which throws and catches exceptions, some exceptions leave it's library bounds - main executable which throws and catches exceptions, exceptions

>> 2. ABI docs for Darwin (x86, x86_64, ppc, ppc64) you might find >> somewhere @apple.com. There you can have all 3 types of PIC code: >> static (no pic at all), DynamicNoPIC and full PIC. > > Okay. We need documentation, what is the difference between > DynamicNoPIC and > full PIC ? The best way to figure this out is to run a small program through and look at

Anton, >> Can I ask what platform ABI's are documented other than Itanium ? > I'd bet all platform ABI are more or less documented. Right. Maybe we should collect references and do some LLVM PIC documentation and put it on LLVM website ? >> I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF >> and MachO backends. > ABI is normally induced

Actually, GCC will generate non-PIC for n64. Maybe that is a recent addition, but we are using its results. Even if PIC may be faster and smaller code, it seems that non-PIC is still useful for bare-metal. That's the driver of my interest. I guess we can just test what happens when that part of the conditional is removed. As a side note, if it isn't supported then we should probably

Hello, Aaron > Can I ask what platform ABI's are documented other than Itanium ? I'd bet all platform ABI are more or less documented. > I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF and MachO backends. ABI is normally induced by platform, not by architecture or object file format (however they can influence on it). 1. Windows is PIC by design. Google for

Hello, Rafael > On linux X86_64, calls to local but externally visible functions > should use the PLT. Access to local (same compilation unit), variables > can just use RIP relative access. Right, this is just optimization. AFAIR, current code already does this for 'normal' PIC - it just checks for linkage and doesn't assemble call via PLT for stuff with internal linkage.

The short: Linking to libspeex.a when generating a .so using libtool results in a non-portability warning. This is due to PIC code and non-PIC code intermingling. How can I go about fixing this whilst still using an installed libspeex present on the user's system? The long: I am using autoconf + libtool to generate a codec plugin for speex (sipXmediaLib), and I'm trying to eliminate

On 07/08/2011 01:25 PM, Yuri wrote: > ELF that MCJIT writes on x86_64 has relocations in it. Particularly, > R_X86_64_PC32 relocations are used for the sections .gcc_except_table > and .eh_frame related to exception processing. > I am not sure where is general documentation on relocation types, > including R_X86_64_PC32. Looks like it's nowhere to be found on the web. > But

Hi Folks - I''m pretty new to ACPI (don''t know my ASL from a hole in the ground :-), but I think the _PRT method has the PIC/APIC cases reversed. I''m looking at tools/firmware/acpi/acpi_dsdt.asl. The ACPI spec says a _PIC method (if defined) will be called with an argument of 1 if the host is using APIC interrupts. If the host is using PIC interrupts instead, it

On Mar 11, 2010, at 6:07 PM, Chris Lattner wrote: > On Mar 11, 2010, at 5:47 PM, Robb Kistler wrote: > >> I'm trying to build a very large shared library (bundle) for PPC on >> Mac OS X 10.5. The build looks something like this, where >> mybundlebitcode.o is the large object >> >> llc -relocation-model=pic -o=mybundle.s mybundlebitcode.o >> gcc

ELF that MCJIT writes on x86_64 has relocations in it. Particularly, R_X86_64_PC32 relocations are used for the sections .gcc_except_table and .eh_frame related to exception processing. I am not sure where is general documentation on relocation types, including R_X86_64_PC32. Looks like it's nowhere to be found on the web. But 32-bit relocation can't be used in 64-bit code since it

Has anyone experimented with generating non-PIC for MIPS64 and the n64 ABI? Currently MipsISelLowering.cpp uses conditions like: if ((getTargetMachine().getRelocationModel() == Reloc::PIC_) || IsN64) { } around any PIC code generation. Is generating non-PIC just untested, or is it known not to work? I can't find any discussion of it anywhere. I ran into this when trying to see why

I have grouped two capi controllers using * as the outgoing msn. when the first two channels are busy normally and I try to use a third channel the channels from the second controller are used. But when a channel is occupied by the capisuite fax and we need a third channel asterisk responds with "every one is busy congested at this time". I think the same behavious would have happened

I have been playing a bit with LLVM again and it looks like the current major missing feature on Linux x86-64 is PIC. Is anyone working on it? If not, I would like to do so. I have the ABI documentation (http://www.x86-64.org/documentation/abi.pdf), but would be glad if someone had some LLVM specific pointers. For example, from the targets that do have support for PIC, which one is the one to be

On Mar 11, 2010, at 5:47 PM, Robb Kistler wrote: > I'm trying to build a very large shared library (bundle) for PPC on Mac OS X 10.5. The build looks something like this, where mybundlebitcode.o is the large object > > llc -relocation-model=pic -o=mybundle.s mybundlebitcode.o > gcc -arch ppc -c -x assembler -o mybundle.o mybundle.s > g++ -o mybundle.bundle -bundle mybundle.o

> Message: 4 > Date: Thu, 27 Oct 2016 22:04:28 +0200 > From: Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] PIC and mcmodel=large on x86 doesn't use any > relocations > Message-ID: <20161027200428.GA2177 at britannica.bec.de> > Content-Type: text/plain; charset=us-ascii > > On

I'm trying to build a very large shared library (bundle) for PPC on Mac OS X 10.5. The build looks something like this, where mybundlebitcode.o is the large object llc -relocation-model=pic -o=mybundle.s mybundlebitcode.o gcc -arch ppc -c -x assembler -o mybundle.o mybundle.s g++ -o mybundle.bundle -bundle mybundle.o -lotherlibrary I get the following error: ld: 32-bit pic-base out of

Hi Folks, I'm wondering if there are people out there who would be interested in what would be involved in developing an interface between R graphics and the 'pic' language. Explanation; 'pic' has been part of the Unix 'troff' typesetting suite since very early days (1970s), and also of the GNU troff: 'groff'. Its function is to act as a preprocessor,